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SECTION  1;  OVERVIEW 


i.  Introduction 

The  primary  objective  of  our  Phase  I  effort  was  to  explore  the  feasibility  of  a 
Na\7-wide  DMSMS  prediction  system  and  develop  improved  methods  of  prediction  or 
devise  methods  where  none  currently  exist.  In  pursuit  of  this  goal,  we  have  investigated 
the  DMSMS  process  at  Navy  sites  including  SPCC,  NUWC  Keyport,  NSWC  Crane,  and 
NAWC  Indianapolis,  as  well  as  at  DESC  and  Wright  Patterson.  We  have  researched  the 
extent  of  the  DMSMS  problem  for  microcircuit  and  non-microcircuit  parts,  such  as 
mechanical  parts,  and  have  identified  and  evaluated  tools  or  processes  currently  in  use. 
These  tools  include  TACTech's  AIM,  GIDEP,  Uwohali's  ECOM,  NUW^C  Keyport's 
Necad,  MOM  tools,  and  MOAT/MOSES  for  microcircuits,  and  HEDRS,  Ships  3M,  and 
Equipment  Health  Model  for  mechanical  parts. 

After  an  extensive  surv'ey  of  the  DMSMS  problem  and  existing  tools,  we  decided 
to  focus  our  efforts  on  microcircuit  obsolescence  prediction,  because  our  study  revealed 
that  other  types  of  parts  are  not  nearly  as  significant  a  DMSMS  problem.  Furthermore,  in 
the  Phase  I  effort  we  concentrated  on  automating  the  largely  manual  obsolescence 
prediction  currently  performed  by  the  MOM  program.  Our  reasons  for  concentrating  on 
automating  the  MOM  prediction  process  include  the  fact  that  commercial  prediction 
systems  such  as  TACTech's  AIM  and  Uwohali's  ECOM  do  not  cover  all  parts  and  thus 
cannot  produce  predictions  for  all  parts  and  additionally  that  the  MOM  program  is  the 
only  program  in  the  Navy  which  performs  its  own  comprehensive  predictions. 

We  used  the  artificial  intelligence  techniques  of  knowledge  engineering,  case-based 
reasoning,  knowledge  base  development  and  object  oriented  programming  to  devise  a 
solution  to  the  obsolescence  prediction  problem.  We  implemented  this  solution  in  a 
prototype  to  prove  its  feasibility  beyond  a  doubt.  We  also  developed  a  preliminary  design 
and  functional  description  for  a  Navy-wide  DMSMS  management  system  which  will  be 
developed  in  a  Phase  II  effort.  This  system  was  also  prototyped  to  demonstrate  the 
proactive  nature  of  our  DMSMS  management  strategies  and  to  establish  the  context  of  the 
prediction  component. 

ii.  Summary  of  Results 

We  accomplished  all  of  our  stated  objectives  and  additionally  implemented  a 
prototype  of  the  Phase  II  DMSMS  system  demonstrating  the  proactive  capabilities  and 
ideas  for  solution  support.  In  summary,  we  produced  the  following  results: 

•  Mechanical  parts  obsolescence  is  not  a  significant  problem. 

•  Microcircuit  parts  obsolescence  is  largely  solution  oriented  not  predictive. 

•  Of  the  predictive  systems/programs  in  existence,  MOM  is  the  most  comprehensive. 
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•  Data  does  not  currently  support  CBR  predictive  techniques  as  proposed  for 

Phase  I  because  data  is  not  standardized,  there  is  missing  information  in  data  records 
and  some  data  is  unavailable. 

•  The  MOM  predictive  process  can  be  automated.  We  did  it  in  a  proof-of-concept 
prototype.  CBR  can  be  used  to  identity  the  predictive  family  so  MOM's  $1  Million 
trends  study  can  be  used.  A  knowledge  based  obsolescence  evaluation  can  be 
performed.  Where  automation  breaks  down,  the  system  can  request  specific  missing 
information  and  complete  the  evaluation. 

•  We  identified  the  structure,  standards  and  required  information  for  collection  of  new 
data  to  allow  more  of  the  MOM  process  to  be  automated,  CBR  for  obsolescence 
prediction  and  even  more  sophisticated  data  analysis  and  trends  forecasting 

•  Designed  and  implemented  a  prototype  of  a  comprehensive  DMSMS  Management 
System  for  proactive  management  of  obsolescence  and  support  for  solutions.  This 
system  permits  integration  of  relevant  databases  and  can  potentially  include  other  parts 
data  such  as  mechanical  and  electronic,  along  with  microcircuit  parts. 

iii.  Conclusions 

In  Phase  I,  we  applied  our  AI  expertise  to  the  problem  of  obsolescence  prediction 
and  DMSMS  management.  We  developed  an  innovative  solution  to  obsolescence 
prediction  by  automating  the  MOM  evaluation  process.  Further,  we  designed  a  proactive 
DMSMS  management  system  which  incorporates  the  prediction  techniques  and  gives 
users  capabilities  well  beyond  any  current  expectations.  The  automated  prediction  process 
results  in  faster  DMSMS  processing  and  allows  engineers  to  deal  with  the  hard  problems 
and  prioritize  their  tasks.  It  is  proactive  so  that  obsolescence  issues  are  identified  earlier. 

It  provides  guidance  through  the  solution  process  and  coordination  of  solution  efforts.  It 
may  be  straightforwardly  expanded  to  include  other  types  of  parts,  and  it  is  owned  and 
controlled  by  the  Navy, 

Through  implementation  of  both  of  these  solutions  in  a  prototype,  we  proved  the 
feasibility  of  our  methods  beyond  a  doubt.  This  effort  laid  the  groundwork  for  the 
successful  implementation  of  the  fully  functional  DMSMS  Management  System  in  Phase 
II. 
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SECTION  II;  DETAILED  DESCRIPTION  OF  RESULTS 


1.0  PROBLEM  IDENTIFICATION 

1 . 1  Background 

The  diminishing  manufacturing  sources  and  material  shortages  (DMSMS)  problem 
has  been  a  concern  for  many  years  throughout  both  military  and  commercial  sectors. 
Weapon  systems'  components  become  obsolete  as  technology  advances.  Manufacturers 
cease  production  of  parts  over  time.  Management  of  microcircuit,  electronic  and 
mechanical  parts,  from  design  to  acquisition,  storage,  use,  and  ultimate  disposal,  has  very 
large  associated  costs  in  terms  of  tracking  and  solution. 

In  recent  years,  more  microcircuit  and  electronic  parts  have  been  used  in  new 
weapon  system  designs  and  redesigns,  resulting  in  shorter  part  life  cycles  as  the 
technology  rapidly  advances.  The  changing  world  economy  and  financial  realities  at  home 
have  decreased  the  defense  budget.  This  has  meant  that  weapon  systems  are  in  use  longer 
than  expected  and  commercial  industries  are  increasingly  independent  of  the  government 
and  cater  less  to  its  specific  needs.  Coping  with  an  increasing  number  of  obsolete  parts,  a 
shorter  time  frame  for  solutions  and  a  restricted  budget,  demands  a  greater  emphasis  on 
obsolescence  prediction  and  proactive  parts  management,  and  better  communication  and 
coordination  of  solutions.  Parts  obsolescence  prediction  has  been  the  focus  of  our  Phase  I 
effort. 

1.2  Challenges 

Obsolescence  prediction  strategies  are  essential  to  effective  parts  management  and 
can  yield  significant  cost  avoidance  advantages.  Calculating  the  usefiil  life  of  a  part  is  as 
much  an  art  as  a  science.  The  key  factors  must  be  identified  and  then  combined  using  an 
assortment  of  principles  and  rules  to  produce  an  obsolescence  estimate.  Even  the  problem 
of  determining  these  significant  factors  can  be  quite  complex.  For  example,  it  is  generally 
accepted  that  technology,  function,  manufacturer  and  suppliers  are  important  factors 
affecting  obsolescence.  Only  recently  has  it  been  discovered  that  a  rise  in  the  price  per 
part  is  also  an  indication  of  impending  obsolescence.  Analysts  have  also  found  that  along 
with  the  number  of  parts  suppliers,  the  rate  at  which  the  number  drops  is  equally 
significant.  Only  through  thorough  analysis  can  these  and  other  non-obvious  factors  be 
identified.  Once  this  has  been  accomplished,  the  task  of  determining  the  principles  by 
which  these  factors  should  be  combined  to  produce  accurate  estimates  is  even  more 
difficult,  since  there  are  few  "hard  and  fast"  rules  to  follow.  Thus,  there  are  significant 
benefits  from  a  decision  aiding  tool  which  would  determine  these  factors  and  combine 
them  appropriately  to  produce  overall  obsolescence  predictions. 
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Proactive  DMSMS  management  is  also  inhibited  by  the  distributed  nature  of  the 
problem  and  the  huge  quantities  of  data  involved.  DMSMS  is  tracked  at  various  sites 
(with  some  duplication  of  effort)  using  different  techniques  and  database  management 
systems.  There  are  no  standard  data  definitions  for  parts  data  and  users  generally  cannot 
communicate  across  these  databases.  Data  records  are  often  incomplete  or  inconsistent. 
For  example,  part  descriptions  and  technology  fields  are  not  always  filled  in,  or  if  they  are, 
they  may  use  different  terminology  or  abbreviations  (e  g.  LINE  DRIVER  / 
TRANSMITTER,  DIFF  and  QUAD  LINE  DRIVER  -  DIFF  (TS)  both  describe  the  same 
part  in  different  databases).  DMSMS  is  not  tied  electronically  to  weapon  systems.  Some 
parts  data  is  unavailable  because  the  government  does  not  know  the  parts  in  "black  box" 
components,  or  great  effort  is  required  to  translate  data  or  drawings  to  electronic  form. 

In  a  domain  affecting  the  entire  Department  of  Defense,  where  rapid  responses  are 
necessary  and  the  cost  of  failure  is  high  (LOT  buys,  retooling,  private  stockpiles,  etc.  are 
expensive),  we  find  a  primarily  reactive  DMSMS  process.  In  general,  the  database 
management  systems,  obsolescence  prediction  techniques  and  DMSMS  management 
protocol  are  not  yet  in  place  for  efficient  or  comprehensive  sharing  of  data  and  solutions. 

Because  of  the  great  importance  and  significant  cost  of  DMSMS  management,  the 
Navy  could  dramatically  benefit  from  intelligent,  automated  parts  obsolescence  prediction 
and  proactive  DMSMS  management.  However,  no  tool  currently  exists  which  is  both 
comprehensive  and  flexible  enough  to  meet  these  needs.  For  this  reason,  the  primary 
objective  of  our  Phase  I  effort  was  to  apply  our  Artificial  Intelligence  (AI)  problem  solving 
expertise  to  this  problem  and  develop  feasible  solutions. 


2  0  PHASE  I  TECHNICAL  OBJECTIVES 

The  overall  Phase  I  objective  was  to  prove  that  an  effective  method  could  be 
achieved  for  identifying  the  factors  and  principles  that  determine  the  useful  life  of  a 
component,  and  combining  them  to  produce  a  reliable  obsolescence  prediction.  Success 
developing  a  proof-of-concept  prototype  for  this  method  would  allow  for  Phase  II  design 
of  a  full-scale  system  containing  a  complete  case  base  of  microcircuit,  electronic  and 
mechanical  components  used  in  U  S.  military  weapons  systems,  as  well  as  more  thorough 
interface  design  and  end-user  performance  testing.  Specifically,  there  were  four  Phase  I 
objectives: 

1  Analyze  current  obsolescence  prediction  techniques,  and  collect  an  initial  case  base 
of  components.  Investigate  the  use  of  case  based  reasoning  for  predicting  parts 
obsolescence. 

2.  Implement  a  proof-of-concept  prototype  obsolescence  prediction  system  using  a 
broad  selection  of  components  as  cases. 

3.  Develop  and  test  several  obsolescence  prediction  algorithms  in  the  prototype. 
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4.  Design  the  full-scale  Phase  II  prediction  system:  The  culmination  of  the  Phase  I 
research  is  a  complete  functional  specification  of  a  parts  obsolescence  prediction  system. 


3.0  ARTIFICIAL  INTELLIGENCE  METHODOLOGIES 

While  we  approached  the  parts  obsolescence  prediction  problem  with  a  number  of 
innovative  ideas  and  extensive  experience  in  the  field  of  AI  and  general  problem  solving, 
we  did  not  wish  to  inappropriately  impose  a  solution  or  methodology  on  the  problem. 
Instead,  we  sought  to  first  thoroughly  understand  the  complexities  of  obsolescence 
prediction,  the  tools  and  techniques  currently  in  use,  and  the  Navy's  future  goals  for 
DMSMS  management.  Using  appropriate  AI  techniques,  we  could  then  tailor  a  solution 
to  the  problem.  The  AI  methodologies  we  drew  upon  as  we  investigated  the  problem 
included  knowledge  engineering/elicitation  techniques,  case-based  reasoning  techniques, 
knowledge  based  development  techniques  and  object  oriented  programming.  Each  of 
these  methodologies  is  described  in  the  following  subsections. 

3 . 1  Knowledge  Engineering/Elicitation 

Knowledge  engineering  is  the  process  of  eliciting  and  organizing  information  from 
experts  in  a  particular  domain,  in  our  case  parts  obsolescence  prediction.  Knowledge 
engineering  is  the  necessary  precursor  to  development  of  a  useful  software  prototype  or 
tool  It  comprises  a  body  of  interview  techniques  which  progress  from  general  discussions 
of  the  domain  to  highly  focused  sessions.  The  typical  steps  in  knowledge  engineering  are. 

1  Hold  general  meetings  with  one  or  more  experts  to  obtain  an  overview  of  the 
problem.  Collect  and  study  relevant  documents  regarding  the  domain. 

2.  Met  with  experts  one  at  a  time  to  discuss  the  details  of  their  job.  Elicit  case 
studies  to  aid  in  the  process  of  learning  about  the  domain.  Discuss  any  questions 
suggested  by  the  collected  documents, 

3.  Observe  the  expert  at  work.  Ask  the  expert  to  explain  the  steps  he  is  going 
through  to  perform  the  job  Ask  which  steps  are  typical  and  which  are  special  purpose. 

4.  Structure  the  knowledge  obtained.  Discuss  the  organization  of  the  knowledge 
with  the  experts. 

5.  Once  a  prototype  has  been  developed,  present  the  software  to  the  experts  and  get 
their  feedback  on  its  correctness  and  solicit  suggestions  for  improvements. 

6.  As  tool  development  progresses,  continue  to  present  and  discuss  the  changing 
versions  of  the  tool  to  the  experts. 
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3.2  Case  Based  Reasoning 

Stottler  Henke  Associates,  Inc.  (SHAI)  is  a  pioneer  in  the  development  and 
application  of  Case-Based  Reasoning  (CBR).  CBR  is  based  on  the  notion  that  people 
often  solve  problems  by  remembering  the  solution  to  a  similar  problem  and  adapting  that 
solution  to  meet  the  current  circumstances.  This  is  the  method  we  sought  to  apply  to 
parts  obsolescence  prediction.  For  an  obsolescence  prediction  system,  the  cases  are 
simply  other  parts,  from  which  inferences  and  comparisons  can  be  made  using  CBR.  The 
interactions  between  the  obsolescence  factors  of  a  part  are  very  difficult  to  quantify  into 
usable  rules  or  principles,  especially  when  some  of  the  factors  may  be  unknown.  The  best 
way  to  make  these  evaluations  is  by  using  information  from  previous  cases  as  a  statistical 
foundation  for  predictive  assessments. 

In  our  investigations  of  the  parts  data  early  in  the  Phase  I  effort,  we  discovered 
that  the  use  of  CBR  as  originally  intended  to  predict  a  part's  life  cycle  and  obsolescence 
based  on  the  known  obsolescence  of  a  similar  part  was  only  marginally  possible.  This  was 
because  many  of  the  fields  of  the  data  records  were  incomplete  or  inconsistent.  This  led 
to  a  more  strongly  knowledge  base  development  oriented  approach  (see  Section  3.3). 
However,  we  found  a  number  of  other  significant  uses  of  CBR  to  aid  in  the  parts 
obsolescence  prediction  process.  These  include  identification  of  a  part's  predictive  family 
based  on  the  similarity  between  its  description  and  the  family's  description,  retrieval  of 
alternate  equivalent  parts,  and  identification  of  solutions  to  similar  parts.  We  also  believe 
our  original  use  for  CBR  will  be  possible  in  tracking  and  analyzing  future  weapon  systems 
when  stringent  data  standards  are  in  place.  These  results  are  discussed  in  more  detail  in 
Section  5.0. 

CBR  systems  offer  enormous  benefits  compared  to  standard  AI  approaches.  The 
knowledge  elicitation  bottleneck  is  largely  circumvented.  Cases  can  be  automatically 
acquired  directly  from  domain  experts.  Rules,  on  the  other  hand,  almost  always  require 
the  intervention  of  a  knowledge  engineer.  Instead  of  having  to  elicit  all  of  the  knowledge 
required  to  derive  a  solution  from  scratch,  only  the  knowledge  required  to  represent  a 
solution  is  needed.  In  simple  applications,  a  case  might  be  represented  as  a  database 
record  of  fields.  Only  the  field  names  and  types  must  be  elicited.  The  data  can  be  entered 
automatically.  So  knowledge  elicitation  is  largely  avoided  with  CBR  and  may  be 
completely  automated  depending  on  the  type  of  application  and  the  expert. 

Conventional  knowledge  base  technology  dictates  a  single,  fixed  problem  solving 
methodology.  With  CBR,  each  case,  in  the  extreme,  can  represent  a  different 
methodology.  Therefore,  many  problem  solving  methodologies  are  represented  and,  since 
new  cases  are  continually  added  automatically,  a  CBR  system's  problem  solving 
methodologies  can  change  with  time,  thus  improving  its  performance  and  staying  up  to 
date  and  relevant  automatically. 
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There  are  significant  advantages  to  using  CBR  in  the  domain  of  obsolescence 
prediction  because  of  the  way  that  knowledge  and  information  are  incorporated  in  a  case 
base.  One  of  the  prime  difficulties  associated  with  obsolescence  prediction  arises  from  the 
fact  that  the  decision  making  is  carried  out  by  one  or  a  few  individuals.  The  experience 
base  of  this  individual  is  likely  to  be  confined  to  a  limited  set  of  domains.  This  difficulty  is 
exacerbated  by  high  turnover  rates,  and  lack  of  interaction  between  geographical  and  even 
functional  locations.  The  use  of  a  case-based  system  which  incorporates  knowledge  from 
all  available  resources  makes  the  same  level  of  information  available  to  all  users,  not  only 
from  expert  to  novice,  but  also  from  functional  area  to  functional  area  and  across 
geographical  locations. 

The  sharing  of  knowledge  that  results  from  universal  use  of  a  central  case  base  has 
many  advantages.  The  adage  "knowledge  is  power"  applies  in  this  case,  because  there  are 
direct  benefits  which  arise  from  the  ability  to  use  the  experiential  knowledge  of  others. 
First,  it  prevents  the  otherwise  inevitable  recurring  encounters  with  the  same  problems. 

For  example,  suppose  that  it  is  determined  at  a  depot  working  on  F-14's  that  a  certain 
microprocessor  chip  will  soon  be  obsolete  in  the  functional  role  it  currently  serves.  This 
knowledge  would  be  very  useful  at  other  depots  working  on  other  planes  that  use  the 
same  chip  for  the  same  function.  If  the  other  units  are  in  different  locations,  it  is  likely  that 
they  will  only  gain  this  knowledge  much  later,  or  never  at  all. 

There  are  often  communication  barriers  between  functionally  different  units  much 
like  those  between  geographically  separate  units,  which  impair  their  use  of  other  units' 
experiential  knowledge.  If  information  on  microcircuit,  electronic  and  mechanical 
components  is  stored  in  a  central  corporate  knowledge  base,  it  can  be  accessed 
immediately  to  produce  unknown  relevant  cases  for  any  given  set  of  circumstances.  This 
presents  an  extraordinary  opportunity  to  cross  these  communication  barriers. 

3.3  Knowledge  Based  Development 

An  important  aspect  of  many  AI  development  efforts  is  the  capture  of  the 
corporate  knowledge  of  the  experts.  By  eliciting  and  storing  the  details  of  a  process, 
novices  can  be  productive  even  when  the  experts  are  unavailable.  For  parts  obsolescence 
prediction,  we  chose  to  model  the  evaluation  process  performed  by  the  Microcircuit 
Obsolescence  Management  (MOM)  engineers.  This  involved  representing  the  significant 
factors  affecting  prediction,  such  as  the  technology,  family,  number  of  suppliers,  etc.  and 
combining  them  algorithmically  in  the  same  way  as  the  experienced  human  engineer.  We 
discovered  that  these  factors  have  different  degrees  of  importance  in  determining  a  part's 
obsolescence  evaluation,  and  that  an  experienced  engineer  can  perform  an  evaluation 
much  more  quickly  and  consistently  than  a  new  engineer.  By  automating  the  prediction 
process,  we  achieve  greater  speed  and  consistency  of  evaluations,  an  audit  trail  of  the 
decisions  made,  permitting  an  explanation  of  the  results,  and  the  capture  of  valuable 
knowledge.  The  details  of  our  solution  are  given  in  Sections  7.0  and  8.0. 
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3.4  Object  Oriented  Programming 


Object  Oriented  Programming  (OOP)  is  a  methodology  for  both  representation 
and  programming.  Using  OOP  techniques,  one  can  define  different  types  of  objects  and 
specialized  program  methods  that  manipulate  them.  We  used  OOP  for  the  development  of 
our  proof-of-concept  prototype.  Objects  and  object  hierarchies  were  used  to  represent 
parts  data  and  the  weapon  system  to  parts  breakdown.  Methods  which  operate  on  the 
data  objects  were  used  to  compute  similarity  and  perform  the  obsolescence  evaluation. 
Object  oriented  images  were  used  to  develop  the  user  interface  of  the  prototype.  In  a  full- 
scale  version  of  the  DMSMS  management  system,  OOP  would  be  used  heavily  for  data 
structure  representation  as  well  as  solutions  to  parts  obsolescence. 


4.0  PHASE  I  TASKS 

There  were  nine  tasks  undertaken  in  Phase  I  to  achieve  the  project  objectives. 
These  tasks  are  listed  below  and  described  in  detail  in  the  subsequent  sections. 

1 .  Review  Obsolescence  Prediction  Domain 

2.  Decide  focus  of  feasibility  study 

3.  Knowledge  Elicitation 

4.  Detailed  design  of  solution 

5.  Prototype  implementation 

6.  Phase  II  Design 

7.  Evaluation  of  solution 

8.  End  of  project  briefing  and  prototype  demonstration 

9.  Final  Report 

4. 1  Review  Obsolescence  Prediction  Domain 

The  first  step  in  our  Phase  I  investigation  was  to  become  thoroughly  familiar  with 
the  DMSMS  problem  and  identify  the  organizations  and  tools  involved  in  DMSMS 
management.  We  examined  relevant  documents  such  as  the  Prediction  Tool  Survey  and 
prepared  a  list  of  questions  to  ask  the  important  players  in  the  domain  (see  Appendix  A). 
We  attended  the  DMSMS  in  Jupiter  Beach,  Florida  and  learned  about  DMSMS  first-hand 
We  visited  each  of  the  sites  involved  in  DMSMS  and  found  out  about  their  role  and  the 
tools  they  use.  We  collected  documents  and  data  for  analysis.  We  followed  up  our  visits 
with  telephone  calls  to  elicit  additional  information. 

These  preliminary  investigations  of  the  DMSMS  problem  allowed  us  to  assess  the 
extent  and  severity  of  the  problem,  the  tools  currently  available,  and  the  Navy's  current 
and  future  needs  in  this  domain. 
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4.2  Decide  focus  of  feasibility  study 

Our  mission  in  Phase  I  was  to  improve  parts  obsolescence  prediction  techniques 
and  to  develop  new  models  of  prediction  where  none  currently  exist.  Our  study  of  the 
DMSMS  problem  and  our  survey  of  the  sites  and  tools  revealed  that  parts  obsolescence 
for  mechanical  parts  is  not  a  substantial  problem  and  some  tools  are  available  to  support  it 
(see  Section  6.0  for  details).  For  this  reason,  we  decided  to  focus  our  feasibility  study  on 
microcircuits. 

We  analyzed  the  collected  information  on  existing  systems  and  tools  and  assessed 
the  value  of  these  efforts  with  respect  to  the  Navy's  needs.  From  this  analysis,  we  further 
focused  on  the  MOM  program  and  decided  to  automate  the  MOM  evaluation  process  and 
prove  the  feasibility  of  this  emulation  through  prototype  implementation.  This  required 
substantial  additional  knowledge  elicitation  and  data  collection. 

4.3  Knowledge  Elicitation 

We  visited  the  MOM  site  again  to  gather  the  details  of  the  evaluation  process  and 
observe  the  MOM  engineers  at  work.  We  asked  them  to  show  us  the  evaluation  process 
for  half  a  dozen  parts  and  explain  their  judgments.  We  identified  the  data  sources  used  in 
the  evaluations  and  collected  data  for  use  in  our  prototype.  We  were  able  to  establish  a 
definition  of  requirements  for  representing  and  implementing  the  MOM  process.  Over 
subsequent  weeks,  we  continued  our  discussions  with  MOM  engineers  about  the  details  of 
evaluation  process,  especially  during  the  our  software  design  work. 

4.4  Detailed  design  of  solution 

Based  on  the  information  collected  from  MOM  engineers  and  data  collection  from 
other  sources,  we  developed  a  prototype  design  for  parts  obsolescence  prediction. 
Additionally,  we  came  up  with  a  concept  for  an  overall  DMSMS  management  system  for 
Phase  II  implementation.  We  decided  which  artificial  intelligence  techniques  could  be 
exploited  and  which  data  sources  should  be  used. 

4 . 5  Prototype  implementation 

We  implemented  the  proof  of  concept  prototype  for  obsolescence  prediction  using 
IntelliCorp's  KAPPA-PC  object-oriented  development  tool  on  a  PC  486  with  Microsoft 
Windows.  In  the  process,  we  learned  a  great  deal  more  about  the  prediction  process  and 
the  realities  of  the  state  of  the  data.  Additionally,  we  implemented  a  prototype  Phase  II 
DMSMS  management  system  to  establish  the  context  of  the  obsolescence  prediction 
component. 
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4.6  Phase  II  Design 


From  our  Phase  I  research  and  the  prototype  development  efforts,  we  were  able  to 
specify  the  functionality  for  a  complete  Phase  II  software  implementation  of  a  DMSMS 
management  system. 

4  7  Evaluation  of  solution 

We  evaluated  our  solution  and  concluded  that  automated  obsolescence  prediction 
is  feasible.  Furthermore,  if  data  standards  are  put  in  place,  more  automation  is  possible 
and  more  analysis  is  possible.  We  also  determined  that  a  proactive  DMSMS  management 
system  is  feasible. 

4.8  End  of  project  briefing  and  prototype  demonstration 

We  prepared  briefing  charts  for  an  end  of  project  meeting  and  a  demonstration 
sequence  to  exhibit  the  important  functionality  of  the  prototype.  The  purpose  of  the 
meeting  was  to  present  our  Phase  I  results,  elaborate  our  solution  to  parts  obsolescence 
prediction  and  the  innovations  in  our  approach,  demonstrate  our  proof-of-concept 
prototype,  and  discuss  our  ideas  for  future  work. 

4.9  Final  Report 

This  final  report  documents  the  Phase  I  research  activities  and  results  and  contains 
a  description  of  the  prototype  and  the  Phase  II  system  specification. 


5.0  TECHNICAL  RESULTS  AND  PHASE  I  ACCOMPLISHMENTS 

In  Phase  I,  we  successfully  completed  all  our  stated  objectives,  and  in  fact, 
achieved  more  than  originally  anticipated.  In  this  section,  we  briefly  enumerate  the 
technical  results.  Sections  6.0  through  10.0  describe  these  results  in  detail. 

1 .  Mechanical  parts  obsolescence  is  not  a  significant  problem. 

2.  Microcircuit  parts  obsolescence  is  largely  solution  oriented  not  predictive. 

3.  Of  the  predictive  systems/programs  in  existence,  MOM  is  the  most  comprehensive. 

4.  Data  does  not  currently  support  CBR  predictive  techniques  as  proposed  for 
Phase  I  because  data  is  not  standardized,  there  is  missing  information  in  data  records  and 
some  data  is  unavailable. 
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5.  The  MOM  predictive  process  can  be  automated.  We  did  it  in  a  proof-of-concept 
prototype.  CBR  can  be  used  to  identify  the  predictive  family  so  MOM's  $1  Million  trends 
study  can  be  used.  A  knowledge  based  obsolescence  evaluation  can  be  performed.  Where 
automation  breaks  down,  the  system  can  request  specific  missing  information  and 
complete  the  evaluation. 

6.  We  identified  the  structure,  standards  and  required  information  for  collection  of 
new  data  to  allow  more  of  the  MOM  process  to  be  automated,  CBR  for  obsolescence 
prediction  and  even  more  sophisticated  data  analysis  and  trends  forecasting 

7.  Designed  and  implemented  a  prototype  of  a  comprehensive  DMSMS  Management 
System  for  proactive  management  of  obsolescence  and  support  for  solutions.  This  system 
permits  integration  of  relevant  databases  and  can  potentially  include  other  parts  data  such 
as  mechanical,  and  electronic,  as  well  as  microcircuit. 


6.0  EVALUATION  OF  EXISTING  PREDICTION  METHODS/TOOLS 

In  order  to  prevent  duplication  of  effort  and  to  better  understand  the  complexities 
of  the  DMSMS  domain,  we  identified  and  evaluated  the  systems  currently  in  use.  The 
next  sections  describe  the  evaluation  criteria  we  began  with,  the  details  of  the  DMSMS 
process  at  various  sites  and  the  detailed  evaluations  of  tools. 

6. 1  Evaluation  Criteria 

The  following  criteria  were  applied  when  considering  the  DMSMS  process  at 
various  sites  and  assessing  the  tools  in  use. 

•  Do  they  predict  or  are  they  users  of  predictions? 

•  Accuracy  of  the  predictions 

•  Completeness  of  databases 

aliases/cross  reference  of  parts 
roll  up  data  from  parts  to  systems 

•  Prediction  by  family  or  technology 

•  Prediction  of  specific  parts'  obsolescence  rather  than  %  of  families 

•  User  friendly 

•  Accessible 

•  Cost  of  prediction  in  terms  of  dollars  or  manpower 

•  Solutions 

how  good  are  solutions? 

do  they  have  access  to  other's  solutions? 
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6.2 


Tools, ^lethods  Evaluated 


6.2.1  Sites  Interviewed 

Ships  Parts  Control  Center  (SPCC) 

SPCC  logistics  personnel  handle  DMS  notices  for  Navy  Supply  managed  parts. 

The  goal  is  for  SPCC  to  manage  only  repairable  items  and  for  DESC  to  manage  all 
electronic  components.  They  basically  react  to  DMS  notices  received;  they  do  not 
perform  any  prediction.  They  coordinate  with  their  users  of  the  DMS  parts  to  determine 
LOT  buy  quantities.  They  access  the  Weapon  Systems  File  to  determine  in  which  systems 
parts  are  used;  they  access  DESC  databases  to  track  down  more  information  on  the  part 
and  related  NSNs;  they  access  databases  to  check  the  current  stock  of  parts  in  Navy  stores 
and  the  current  stock  at  DESC;  they  also  have  local  databases  to  track  their  processing  of 
DMS  notices. 

Defense  Electronic  Supply  Center  tDESCt 

DESC  is  the  DLA  center  which  handles  logistics  for  electronic  commodity  classes. 
They  receive  DMS  notices  and  coordinate  with  users,  such  as  SPCC,  to  perform  LOT 
buys.  They  only  react  to  DMS  notices.  They  do  not  perform  any  predictions.  The 
following  six  commodity  classes,  ordered  from  highest  to  lowest  by  number  of  DMS 
notices,  represent  75%  of  their  DMS  cases: 

5962  -  Microcircuits 
5961  -  Semiconductors 
5960  -  Electron  Tubes 
5935  -  Connectors,  Electrical 
5905  -  Resistors 
5910  -  Capacitors 

Wright  Patterson  Air  Force  Base 

Wright  Patterson  is  responsible  for  establishing  the  Air  Force  DMSMS 
policies/program.  They  are  in  the  process  of  collecting  information  on  the  current  DMS 
efforts  within  the  Air  Force  and  are  also  investigating  DMS  tools  and  technologies  outside 
the  Air  Force  to  consider  which  to  use  for  the  Air  Force.  Their  view  is  that  the  Wright 
Patterson  office  will  provide  centralized  support  to  the  program  offices  to  make  their 
decision  processes  related  to  DMS  easier.  Currently,  the  Air  Force  has  not  coordinated 
DMSMS  efforts  service-wide. 

NUWC  Kevport 

The  Keyport  site  supports  acoustics  systems,  towed  systems,  and  combat  control 
systems.  They  support  the  DMS  management  for  programs  assigned  to  their  site.  They 
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provide  proactive  assessments  of  systems  before  problems  arise,  processing  of  DMSMS 
alerts  against  system  breakdowns,  and  the  generation  of  solutions  to  DMSMS  problems. 
At  Keyport,  they  perform  assessments  of  systems  using  their  Electronic  Component 
Technology  Analysis  (ECTA)  process.  Their  assessments  consist  of  calculating  average 
life-cycle  codes  for  systems.  Their  NECAD  database,  described  below,  is  used  to  support 
these  analyses.  They  estimated  that  99.9%  of  their  DMS  cases  concern  electronic  parts. 

DMS  Technology  Center  ('PTC')  /  NSWC  Crane  /  NAWC  Indianapolis 

The  recently  formed  DMS  Technology  Center  combines  the  DMSMS  efforts  of 
NSWC  Crane  and  the  Health  of  Naval  Aviation  (HONA)  and  Microcircuit  Obsolescence 
Management  (MOM)  programs  from  NAWC  Indianapolis.  The  Crane  site  is  similar  to  the 
Keyport  site  in  providing  direct  program  support  for  DMS  issues.  The  MOM  program 
was  designated  by  the  Naval  Air  Systems  Command  as  the  lead  activity  in  dealing  with 
microcircuit  obsolescence  issues.  They  provide  two  primary  functions  to  their  customers: 
obsolescence  alerts  and  Microcircuit  Technology  Assessments  (MTAs).  The  MOM 
program  is  described  in  more  detail  below. 

NSWC  Philadelphia  Carderock  Division 

The  Carderock  Division  is  responsible  for  handling  hull,  mechanical,  and  electrical 
(HM&E)  tech-referrals.  Unavailable  HM&E  parts  are  documented  under  an  "obsolete 
without  replacement"  tech-referral.  There  are  many  kinds  of  tech-referrals  with  obsolete 
being  only  one  kind.  Non-procurable  parts  are  not  classified  as  DMS  by  logistics  groups 
unless  a  DMS  notice  is  received.  Unfortunately,  the  majority  of  the  historical  data  on 
these  tech-referrals  has  either  been  lost  or  destroyed  with  only  the  last  3  years  currently 
available.  Approximately  100  of  these  type  of  tech-referrals  are  processed  in  a  quarter. 
Engineers  are  assigned  the  tech-referrals  and  develop  the  solutions  to  these  problems. 

The  following  reasons  were  cited  for  HM&E  obsolete  tech-referrals.  The  demand 
for  these  parts  is  low.  Many  of  the  parts  are  older  than  50  years.  Only  a  few  parts  of  each 
type  are  on  a  ship,  and  the  parts  have  a  high  reliability  and  may  not  have  been  replaced  in 
10  to  30  years.  Because  of  the  high  reliability,  the  Navy  hasn't  purchased  any  of  these 
parts  or  hasn't  purchased  enough  to  keep  the  manufacturers  in  business.  zAdditionally, 
some  small  businesses  have  been  frustrated  with  the  long  delays  in  obtaining  payments 
from  the  government  and  have  stopped  doing  business  with  the  government. 

The  main  problem  with  these  parts  is  the  lack  of  quality  drawings  for  these  parts. 

In  many  cases,  the  drawings  of  the  parts  were  not  purchased;  so  the  exact  specifications 
are  not  knowm.  Most  HM&E  parts  are  considered  commercially  available  so  drawings  are 
usually  not  required  as  frequently  as  they  are  for  electronic  parts.  If  a  drawing  is  available, 
many  times  the  quality  of  the  drawing  is  poor  because  of  the  age  of  the  drawing,  because 
the  microfiche  of  the  drawing  was  poorly  done,  or  because  the  drawing  has  been  copied 
too  many  times.  If  an  acceptable  drawing  is  available,  the  part  can  generally  be 
manufactured.  Much  time  is  spent  finding  piece  parts  to  fix  the  parts  or  to  find  suitable 
replacements. 
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Other  Sites  Handling  Mechanical  Parts 


Many  other  sites  which  handle  mechanical  parts  were  interviewed.  These  sites  all 
indicated  that  the  obsolescence  problem  for  mechanical  parts  was  a  minor  problem. 

The  sites  and  organizations  interviewed  included: 

•  Engineering  Branch  at  ASO 

•  ASO  personnel  handling  the  FA/18  Program 

•  FA/18  Program  -  McDonnell  Douglas  in  St.  Louis 

•  P3  Program 

•  F 14  and  EA60  Programs  in  Norfolk 

•  F 1 6  Program  in  North  Island 

.  DLA  including  DGSC,  DISC,  and  DCSC 

6.2.2  Tools/Methods 
TACTech 


TACTech's  system  provides  information  to  aid  the  management  of  microcircuit 
and  discrete  part  obsolescence.  The  system  provides  a  life  cycle  code  for  each  part.  The 
code,  a  number  from  1  to  5,  indicates  the  part's  current  position  in  the  ten  year 
technological  life  cycle.  The  system  is  also  capable  of  producing  an  off-line  Product 
Analysis  report  for  the  user's  parts  list. 

Two  functions  of  this  system  are  most  utilized  by  users  whom  we  interviewed. 

The  first  function  is  the  identification  of  detailed  part  information  from  part  numbers.  The 
TACTech  system  only  contains  vendor  part  numbers  and  military  numbers.  It  does  not 
accept  NSNs  or  SCDs.  The  system  does  provide  cross  reference  information  between  the 
military  numbers  and  vendor  part  numbers  to  aid  the  identification  of  equivalent  parts,  but 
the  system  only  contains  military  parts,  either  standard  military  parts  or  parts  tested  to 
MIL-STD-883.  In  fact,  some  users  rely  on  the  fact  that  if  a  part  is  in  TACTech  then  it  is 
of  military  quality.  The  second  popular  feature  of  TACTech  is  the  life  cycle  code.  Many 
users  utilize  these  codes  to  calculate  the  obsolescence  of  their  systems  by  averaging  the 
codes  of  the  parts  in  the  system.  Because  some  parts  are  not  in  TACTech,  these  system 
averages  do  not  include  all  the  parts  in  a  given  system.  TACTech's  Product  Analysis 
report  contains  the  following  sections: 

•  System  Life  Cycle  Matrix  which  summarizes  the  number  of  parts  in  each  life  cycle 
stage. 

•  Sourcing  Depth  By  Product  Type  which  details  the  number  of  manufacturers  of 
each  part  and  the  number  of  parts  from  each  manufacturer. 

•  Single  Source/No  Available  Source  Summary  which  lists  parts  with  zero  or  one 
source. 
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•  Detailed  Parts  List  Breakdown  which  identifies  potential  alternative  parts  and 
sources  and  also  possible  sourcing  issues. 

•  Parts  Excluded  From  Analysis  which  contains  parts  not  in  TACTech's  database. 

•  Potential  Sourcing  Issues  which  summarizes  all  potential  sourcing  issues  with  the 
reason  for  the  problem. 

Although  these  reports  contain  much  detailed  information,  none  of  the  users  we 
interviewed  during  our  Phase  I  effort  mentioned  utilizing  these  reports.  One  drawback  of 
these  reports  is  that  much  of  the  information  is  valuable  the  first  time  the  report  is  run,  but 
in  future  reports  the  additions  and  changes  from  the  previous  report  are  the  most 
important  information.  TACTech's  system  is  available  either  via  a  remote  connection  to 
their  main  computer  using  a  modem  or  installed  directly  on  customer's  computers. 

PROS:  life  cycle  code  of  parts;  cross  reference  of  military  numbers  and  vendor  part 
numbers;  processing  of  alerts  against  parts  list. 

CONS:  missing  parts  -  compromises  overall  life  cycle  estimates;  life  cycle  code  only 
indicates  how  old  the  technology  is,  not  when  it  will  be  obsolete;  text-based  screens  -  not 
very  user-friendly;  only  one-level  of  breakdown  -  parts  list  to  parts;  only  solution  support 
is  for  alternative  parts;  no  visibility  to  other  users  with  the  same  problems. 

Government  Industry  Data  Exchange  Program  fGIDEPI 

GIDEP  is  chartered  to  provide  for  the  full  exchange  of  information  between 
industry  and  government  organizations.  GIDEP  provides  electronic  access  to  the 
following  types  of  data:  engineering  data,  metrology  data,  product  information,  failure 
experience  data,  reliability/maintainability  data,  and  urgent  data  requests.  The  production 
information  includes  DMSMS  Notices.  Currently,  GIDEP  is  enhancing  the  DMSMS 
Notice  processing  to  create  the  DMSMS  Database. 

GIDEP  currently  supports  document  retrieval  for  DMSMS  Notices.  The 
following  fields  are  available  for  document  retrieval:  document  number  (a  GIDEP  assigned 
number),  document  date,  cage  code  of  the  manufacturer,  participant  code  (a  GIDEP 
assigned  code,  e  g.  CE9  =  TI),  a  document  designator  (identifies  the  type  of  data: 
engineering,  metrology,  etc  ),  a  microfiche  locator,  and  the  title  of  the  document.  The 
current  system  can  only  search  for  documents  based  on  these  fields.  For  example,  the 
system  cannot  electronically  search  for  specific  vendor  part  numbers.  The  system  is  suited 
for  visual  review  of  the  DMSMS  Notifications  documents. 

The  development  of  the  DMSMS  Database  is  presently  underway.  This  effort  is 
split  into  two  phases.  The  first  phase  converts  the  DMSMS  notification  processing  to  a 
relational  database.  Much  of  the  information  currently  available  only  by  visually  reviewing 
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the  documents,  such  as  vendor  part  numbers,  will  be  available  in  fields  of  the  relational 
database.  With  this  conversion,  all  of  the  advantages  of  relational  database  technology 
will  also  be  available  to  users.  This  phase  also  augments  the  data  in  GIDEP  for  each 
DMSMS  notice  to  include  the  ICP  for  the  part,  the  address  and  phone  number  of  the  ICP, 
the  routing  identification  code  (RIC)  for  the  part,  the  manufacturer's  point  of  contact  with 
address  and  phone  number,  and  a  35  character  field  to  record  the  solution  or  status.  The 
second  phase  implements  a  second  database  to  provide  a  means  for  government  ICPs  and 
managing  activities  to  communicate  their  DMSMS  current  and  projected  future  demands. 
While  any  user  of  GIDEP  will  be  allowed  to  access  the  information  in  the  first  phase 
database,  the  information  in  the  second  phase  database  will  be  restricted  to  the  appropriate 
users.  The  system  is  accessed  remotely  from  personal  computers.  GIDEP  recently 
released  user-fnendly  software  for  accessing  their  system.  This  user-friendly  software  has 
greatly  increased  the  use  of  the  GIDEP  system. 

PROS;  one  central  repository  of  DMSMS  notifications,  provides  means  for  logistic 
personnel  and  their  managing  activities  to  communicate  and  coordinate  responses  to 
DMSMS  notices;  relational  database  will  provide  access  to  more  details  and  lead  to  more 
productive  use. 

CONS,  only  reactive  -  database  entry  only  occurs  once  a  DMSMS  notice  is  received; 
DMSMS  database  seems  tailored  for  systems  supported  by  logistics  groups,  cannot 
upload  weapon  system  breakdown/parts  list  into  system  to  process  DMSMS  notices 
against;  one  field  for  solution  support  for  all  affected  systems  seems  inadequate. 

Uwohali's  Electronic  Component  Obsolescence  Management  lECOMI 

The  development  of  ECOM  was  started  to  help  manage  obsolescence  on  the  Air 
Force's  F-15  AN/APG-63  radar  system  and  today  manages  parts  on  the  top  15  systems  in 
the  F-15.  This  system  is  a  fairly  comprehensive  obsolescence  management  system  for  this 
weapon  system.  The  system  cross-references  OEM/SCD  numbers,  MILSPEC  number, 
NSNs,  vendor  part  numbers,  hybrid  part  numbers,  and  generic  part  numbers  for  each 
specific  device.  Uwohali  inputs  the  weapon  system  breakdown  which  they  call  the 
Specific  Weapon  System  data.  Additionally,  the  system  can  provide  compliant  and 
equivalent  alternate  parts.  Uwohali  performs  annual  reviews  of  manufacturers  and  tracks 
"high-risk"  manufacturers.  Periodic  updates  of  the  part  data  are  delivered  to  users. 

Projecting  future  obsolescence  is  one  function  of  the  ECOM  system.  The 
prediction  is  very  straightforward.  The  prediction  is  performed  only  for  microcircuit  and 
hybrid  parts.  The  projection  uses  two  parameters.  One  parameter,  P,  is  the  point  at  which 
all  components  of  a  specific  technology  are  no  longer  available.  The  second  parameter,  a, 
is  the  point  at  which  a  family  of  components  within  the  technology  starts  to  become 
unavailable.  Microcircuits  are  divided  into  16  separate  families  such  as  logic  devices.  A 
straight  line  projection  from  a  to  P  is  assumed.  This  projection  is  used  to  predict  the 
number  of  devices  in  a  system  which  will  be  obsolete  at  a  point  in  the  future.  For 
example,  if  the  straight  line  projection  indicates  that  30%  of  the  parts  within  a  family  are 
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obsolete  in  1996,  then  their  projection  will  predict  that  30%  of  the  parts  in  that  family 
within  a  particular  system  will  be  obsolete  in  1996,  but  it  will  not  identify  which  particular 
parts  will  be  obsolete. 

The  system  runs  on  IBM-compatible  notebook  computers  in  a  standalone 
configuration.  Updates  to  part  availability  are  delivered  monthly.  The  system  provides  a 
fairly  user-fiiendly  interface  including  3-D  graphs  to  depict  future  part  availability. 

PROS:  Part  number  cross-referencing;  supports  identification  of  possible  alternative 
parts. 

CONS:  Standalone  configuration  precludes  sharing  solution  data;  prediction  based  on  a 
small  number  of  fairly  large  families  and  not  function  specific;  dependent  on  Uwohali  for 
system  breakdown  input  and  new  part  data. 

US  Army  Missile  Command's  MOAT  /  MOSES 

The  Microcircuit  Obsolescence  Analysis  Tool  (MOAT),  developed  by  BDM 
Federal,  Inc.,  is  a  LAN  system  incorporating  TACTech,  CAPS,  and  a  MICOM  internal 
configuration  system.  The  system  contains  information  on  parts  including  which  systems 
use  the  part,  which  boards  use  the  part,  army  part  numbers,  generic  part  numbers, 
description,  obsolescence  status,  upgrades,  downgrades,  manufacturers,  and  known 
solution  approaches. 

The  system  does  not  perform  predictions.  Predictions  are  manually  performed  by 
engineers  who  base  their  predictions  on  the  component  technology,  the  life-cycle  code 
from  TACTech,  and  information  from  vendor  contact.  The  accuracy  of  these  predictions 
has  not  been  evaluated. 

The  Microcircuit  Obsolescence  Solutions  Evaluations  System  (MOSES)  is 
currently  under  development.  This  expert  system  will  allow  microcircuit  engineering 
analysis  to  consistently  and  accurately  identify  obsolescence  solutions.  Factors  in 
evaluation  solution  options  include  the  engineering  cost  of  alternative  solutions,  the 
pervasiveness  of  non  available  components  within  the  system,  and  the  weapon  systems 
life-cycle  status  until  its  planned  improvement  or  end-of-life.  This  system  will  document 
the  decision  process  for  each  problem  and  will  enforce  a  standard  solution  process. 

PROS:  documentation  of  the  solution  decision  process;  standardization  of  the  solution 
process. 

CONS:  Manual  predictions;  network  does  not  provide  off-site  access,  MOSES  would 
need  to  be  tailored  for  other  organizations 
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NUWC  Keyport's  Navy  Electronic  Component  Application  Database  fNECAD^ 


This  database  developed  for  NUWC  Keyport  contains  unit  part  breakdowns  and 
DMSMS  case  history  information.  This  database  is  used  to  generate  Electronic 
Component  Technology  Analyses  (ECTAs)  and  to  identify  which  units  are  affected  by 
DMSMS  notices. 

Unit  breakdowns  only  exist  in  NEC  AD  if  an  ECTA  has  been  performed  for  the 
unit.  Half  of  the  effort  to  generate  an  ECTA  is  spent  obtaining  the  indentured  parts  list  of 
the  unit.  Initially,  Weapon  System  File  information  is  extracted  for  the  unit.  But  in  most 
cases,  their  units  have  circuit  cards  as  the  lowest  repairable  item,  so  the  microcircuit  part 
information  for  these  cards  was  not  originally  purchased  from  the  OEM  and  is  not 
contained  in  the  Weapon  System  File. 

The  ECTA  provides  a  life-cycle  projection  of  the  unit.  Known  DMSMS  alerts  are 
run  against  the  parts  breakdown,  and  the  average  life-cycle  of  the  parts  is  calculated.  The 
life-cycle  codes  used  for  an  ECTA  are  TACTech's  life-cycle  codes  for  the  parts.  Because 
TACTech  does  not  contain  all  parts,  the  ECTAs  cannot  include  all  the  parts  of  the  units. 
The  typical  cost  of  performing  an  ECTA  is  $40,000.  After  an  ECTA  is  performed,  new 
DMSMS  alerts  can  be  checked  against  the  unit  part  breakdown. 

NECAD  is  also  used  to  track  DMSMS  cases.  Cases  document  the  actions  and 
solutions  for  a  DMSMS  problem.  A  case  is  created  for  a  vendor  part  affecting  a  group  of 
very  similar  units.  In  addition  to  the  part  and  affected  units,  the  case  also  documents  the 
manufacturer  and  any  relevant  drawing  numbers,  and  the  date  the  case  was  created.  A  log 
of  actions  taken,  such  as  important  phone  conversations  and  their  results,  are  recorded  in 
the  case  along  with  the  date  of  the  action.  The  log  also  records  important  information 
such  as  cost  estimates  and  LOT  buy  calculations. 

PROS:  DMSMS  case  tracking  system;  ability  to  check  DMS  alerts  against  unit 
breakdowns. 

CONS:  Dependent  on  TACTech  life  cycle  codes;  alternative  part  identification  depends 
on  other  databases. 

MOM  Systems 

The  MOM  program  provides  two  major  functions  for  microcircuit  and 
semiconductor  parts  to  their  customers:  obsolescence  alerts  and  Microcircuit  Technology 
Assessments  (MTAs).  They  utilize  four  in-house  computer-based  tools  in  addition  to 
commercial  tools.  The  in-house  tools  are  the  MOM  Electronic  Bulletin  Board  Service, 
the  MOM  Database,  the  Technology  Trends  Forecast  (TTF),  and  the  Technology 
Assessment  Database  (TAD).  The  commercial  tools  which  they  utilize  are  IHS's 
PartsMaster  and  Haystack,  TACTech,  and  IC  Master  CD-ROM  Plus.  The  MOM 
program  only  provides  solutions  in  the  form  of  alternative  parts.  Their  assessments  are 
delivered  to  the  program  managers  who  must  decide  on  the  solution. 
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The  MOM  Electronic  Bulletin  Board  Service  allows  customers  to  search  for 
microcircuit  obsolescence  notices  and  affected  systems  using  queries.  The  system  is 
accessed  remotely  using  a  modem  and  terminal  emulation  software.  Users  may  query  to 
find  obsolescence  notices  affecting  vendor  part  numbers,  NSNs,  military  numbers,  etc. 
Standard  database  query  functionality  such  as  wild  card  searches  are  also  provided.  Users 
may  view  or  download  the  content  of  the  obsolescence  notifications.  Additionally,  users 
whose  system  breakdown  has  been  entered  into  the  MOM  database  may  query  to  see  if 
any  obsolescence  notifications  have  affected  their  systems. 

The  MOM  database  contains  comprehensive  information  on  microcircuits  and  the 
Weapon  System  Breakdown  information  in  an  Oracle  database  running  on  a  VAX 
computer.  The  information  loaded  into  this  database  includes  data  from  ASO,  SPCC,  and 
DLA.  Additionally,  information  obtained  during  the  MTA  process  is  also  loaded  into  the 
system.  The  system  is  only  used  internally  by  the  MOM  engineers,  usually  in  batch  mode, 
and  a  user-friendly  interface  for  customers  has  not  been  developed. 

The  TTF  is  both  an  internal  document  and  a  menu-driven  database  tool  for 
forecasting  microcircuit  and  discrete  family  trends.  The  database  tool  runs  in  a  standalone 
mode  on  an  IBM-compatible  PC.  The  tool  is  utilized  in  evaluating  parts  during  the 
development  of  MTAs.  For  each  of  the  1000  technology  and  function  combinations,  it 
contains  current  life-cycle  code,  future  life-cycle  code,  preferred  function  and  technology 
combination  for  new  designs,  and  an  indicator  of  whether  the  market  demand  is  increasing 
or  decreasing.  Each  update  of  the  TTF  costs  approximately  $1  million. 

The  TAD  is  a  standalone  IBM-compatible  PC  database  used  to  store  and  generate 
the  information  required  to  produce  MTA  reports.  The  part  information  for  one  MTA  can 
be  re-used  in  an  MTA  for  another  system  containing  some  of  the  same  parts.  Parts  not 
used  in  previous  MTAs  must  be  entered  by  hand.  The  TAD  is  set  up  to  hold  a  single  list 
of  parts  for  each  case/report. 

Using  the  tools  mentioned  above,  the  MOM  engineers  perform  an  assessment  for  a 
list  of  parts.  First,  the  engineers  obtain  the  following  information  for  each  part;  SCD 
number,  generic  part  number,  vendor  part  number,  military  number,  active  sources, 
technology,  package  style,  device  description,  device  function,  and  technical  notes.  They 
start  with  as  much  information  from  the  customers  as  possible.  For  parts  in  previous 
MTAs,  they  utilize  the  information  already  in  TAD.  For  new  parts,  they  use  their 
commercial  databases,  data  books  in  their  library,  and  phone  calls  to  vendors  to  identify 
these  required  fields.  Most  of  these  fields  have  standard  formats  which  are  detailed  in 
their  Microcircuit  Technology  Assessment  Procedures  and  Guidelines  (MAP AG) 
Handbook.  After  this  required  information  is  obtained,  the  MOM  engineers  assign  an 
evaluation  code  to  the  part.  The  evaluation  codes  are  I,  A,  S,  N,  and  O  which  represent 
Introductory,  Acceptable,  Suspect,  Near  Obsolete,  and  Obsolete.  They  follow  the 
guidelines  of  the  MAP  AG  to  assign  these  codes  taking  into  account  the  information  in  the 
TAD  and  the  forecasting  trends  from  TTF.  The  MTAs  go  through  an  internal  review 
process  before  they  are  delivered  to  the  customers. 
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PROS:  Comprehensive  evaluation  process;  large  amount  of  part  and  system  breakdown 
information  has  been  collected,  ability  to  check  obsolescence  alerts  against  system 
breakdowns. 

CONS:  Tools  not  integrated  -  some  batch,  but  mainly  manual  transfer  of  data  between 
systems;  MTAs  are  only  performed  on  request  and  are  not  automatically  updated  as  parts 
information  is  updated;  assessments  are  somewhat  subjective  in  gray  areas  because  of 
differences  between  engineers. 

HM&E  Equipment  Data  Research  System  (HEDRSt 

The  HEDRS  system  is  extensively  used  by  the  NSWC  Philadelphia  Carderock 
Division  to  solve  obsolete  tech-referrals  for  HM&E  parts.  This  system  is  managed  by  the 
Naval  Sea  Logistics  Center.  The  system  is  available  on  one  CD-ROM.  The  system  is  a 
compilation  of  many  databases  and  files  and  contains  four  main  modules.  One  of  these 
modules  is  the  DMSMS  Equipment  Processing  Module.  The  Engineering  Support  Code 
(ESC)  field  is  contained  within  one  of  these  databases.  The  value  of  this  field  is  one  of 
twelve  values  indicating  the  ability  to  obtain  the  part.  Input  for  this  field  is  obtained  from 
a  manufacturer  survey  to  determine  if  they  still  can  manufacture  and  support  the  parts. 

The  information  in  this  system  is  for  equipment  level  parts  such  as  pumps  and  motors. 
Only  equipment  with  an  assigned  APL  is  in  the  system.  Much  time  was  spent 
standardizing  the  information  in  this  database  so  that  information  on  similar  parts  could  be 
effectively  retrieved  and  processed  by  a  computer.  Other  modules  of  the  HEDRS  system 
may  be  used  to  find  parts  with  similar  characteristics  as  a  means  to  identify  alternate  parts 
or  sources.  The  User's  Manual  for  this  system  states  that  "over  half  of  the  approximately 
200,000  equipment  installed  in  the  Active  Fleet  have  a  population  of  five  or  less." 

Ships'  Maintenance  and  Material  Management  B-M)  System 

This  system  contains  preventive  and  corrective  maintenance  performed  and  the 
parts  which  were  required  and  replaced  during  the  maintenance.  The  system  is  maintained 
by  the  Naval  Sea  Logistics  Center  and  runs  on  the  same  computer  as  the  Weapons  System 
File.  Data  is  available  back  to  1972,  but  only  five  years  are  available  on-line.  The  data  in 
the  system  can  be  used  to  calculate  failure  rates,  demand  for  parts,  and  MTBF,  and  tools 
exist  to  help  obtain  these  calculations.  The  information  in  this  system  is  available  to  on¬ 
line  users  and  also  available  to  non-users  in  hard-copy  reports. 

Equipment  Health  Model 

This  Logistics  Macro  System  Health  Model  was  originally  developed  by  Research 
Analysis  Corporation  (RAC).  The  model  is  based  on  seven  factors  which  work  separately 
and  in  combination  to  calculate  a  health  prediction  for  a  system.  The  system  has  been 
used  by  the  Port  Hueneme  Division  of  NSWC.  So  far  the  system  has  only  been  used  on 
microcircuits,  but  it  has  the  capability  to  be  used  on  HM&E  data  as  well.  Sources  of  data 
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for  this  system  include  the  Weapons  System  File,  The  Ship's  3M  System,  IHS,  and 
logistics  databases.  The  systems  run  on  an  IBM-compatible  computer. 

6.3  Assessment  of  the  Navy's  DMSMS  Problem  and  Conclusions 

Based  on  our  evaluations,  we  are  able  to  conclude  that  DMSMS  is  not  a 
significant  problem  for  mechanical  parts.  Further,  most  DMSMS  systems  are  reactive,  not 
predictive.  Of  the  predictive  systems  available,  MOM  appears  to  be  the  most 
comprehensive  in  terms  of  the  factors  considered  for  obsolescence  prediction,  use  of 
extensive  life  cycle  information,  availability  of  a  large  amount  of  part  and  system 
breakdown  information,  and  completeness  of  data.  For  this  reason,  the  focus  of  the 
remainder  of  the  Phase  I  effort  was  on  improving  and  automating  the  MOM  prediction 
process. 


7.0  SOLUTION:  AUTOMATED  OBSOLESCENCE  PREDICTION  AND 
PROACTIVE  DMSMS  MANAGEMENT 

7. 1  Description  of  our  Solution 

While  the  primary  objective  of  our  Phase  I  effort  was  obsolescence  prediction,  we 
learned  considerable  information  about  the  DMSMS  process,  the  Navy's  needs,  and  future 
requirements  of  the  program.  From  this  knowledge,  we  were  also  able  to  design  a 
solution  for  comprehensive,  proactive  DMSMS  management,  of  which  prediction  is  an 
integral  part.  Both  these  aspects  of  our  solution  are  described  in  the  sections  below. 

7.1.1  Automated  Obsolescence  Prediction 

To  automate  the  MOM  prediction  process,  we  must  replicate  the  steps  MOM 
engineers  carry  out  wherever  possible  and  provide  guidance  and  support  for  those 
functions  requiring  human  involvement,  such  as  research  into  weapon  system  to  parts 
breakdown  or  telephone  calls  to  suppliers.  The  data  for  the  MOM  process  is  derived  from 
numerous  sources  including  commercial  parts  databases  and  a  technology  trends  forecast 
database  compiled  every  two  years  for  1000  different  families  of  parts. 

When  tasked  to  evaluate  obsolescence  issues  for  a  weapon  system,  MOM 
engineers  identify  the  constituent  parts  either  from  existing  databases  or  through 
investigations  in  manuals  and  drawings,  determine  the  family  of  the  part,  examine  the 
trends  data  for  that  family,  and  along  with  nine  other  evaluation  criteria,  produce  an 
evaluation  code  for  each  part:  [A]  for  acceptable,  [S]  for  suspect,  [N]  for  near  obsolete, 
and  [O]  for  obsolete. 
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Because  parts  do  not  have  standardized  descriptions,  the  important  process  of 
matching  the  part  with  a  particular  family  is  very  challenging.  Our  approach  is  to  apply 
CBR  techniques  to  process  the  text  description  of  the  part  and  match  it  to  the  text 
description  of  the  family.  The  only  other  data  field  that  has  proved  relevant  and  is  usually 
available  is  the  technology,  which  is  used  to  assist  this  process. 

Once  the  family  of  the  part  is  identified,  the  corresponding  technology  trends 
forecast  may  be  obtained  in  a  straightforward  manner  from  the  trends  database.  This  is 
one  of  the  most  important  factors  in  the  overall  evaluation  of  the  part's  obsolescence.  We 
have  developed  an  expert  system  to  aid  in  the  assessment  of  the  remaining  factors  and  in 
weighting  the  factors  appropriately  to  produce  an  overall  evaluation  code  for  the  part. 

Unlike  current  DMSMS  prediction,  our  prediction  is  proactive  as  well  as  reactive. 
These  capabilities  are  described  below. 

Proactive  Capabilities 

•  Program  managers  are  automatically  informed  when  an  evaluation  code  for  a  part  in 
their  weapon  system  changes. 

•  System  identifies  all  weapon  systems  affected  by  a  bad  part  or  DMS  notice. 

•  System  identifies  critical  parts  so  the  operator  can  prioritize  tasks  wisely.  For 
example,  a  critical  part  might  be  one  which  is  [S]uspect  but  almost  [N]ear  Obsolete.  If 
its  number  of  suppliers  were  to  drop  from  three  to  two,  its  category  would  change. 

The  operator  could  then  check  on  those  suppliers  more  frequently  than  usual. 

•  System  produces  action  items  for  the  operator  to  perform  that  are  relevant  only  to  his 
system. 

•  Particular  weapon  systems  or  parts  may  be  run  through  the  system  periodically. 


•  Users  may  input  a  weapon  system  or  parts  list  and  get  an  evaluation. 

7.1.2  DMSMS  Management  System  (DMS3) 

The  Navy-wide  DMSMS  management  system  will  address  the  proactive 
management  of  DMSMS  and  allow  coordination  of  solutions  within  the  Navy.  The 
system  will  not  replicate  existing  functionality  available  elsewhere.  GIDEP,  for  example, 
will  be  integrated  with  the  DMSMS  management  system.  GIDEP  will  be  the  DoD 
database  for  DMSMS  notifications.  GIDEP  will  also  provide  for  the  coordination  of 
logistic  organization  resolutions  to  DMSMS  notifications.  These  GIDEP  functions  only 
provide  for  coordination  of  the  reactive  management  of  DMSMS. 


22 


Many  dilferent  categories  of  users  of  the  Navy-wide  system  will  exist.  Weapon 
system  managers,  one  of  the  most  important  users,  will  use  the  prediction  system  to  assess 
the  components  in  their  weapon  systems  and  formulate  strategies  and  plans  to  manage  the 
problem  before  they  receive  DMSMS  notifications.  During  design  and  production,  parts 
lists  of  proposed  systems  will  be  run  through  the  system  to  screen  for  obsolescence. 
Logistics  and  supply  personnel  will  run  analyses  on  the  data  in  the  system  to  determine 
trends.  Engineers  will  use  the  system  to  review  solutions  to  similar  problems,  determine 
solutions  to  new  problems,  and  to  document  and  track  their  solutions.  Experts  on  parts 
and  prediction  will  monitor  and  maintain  the  system  and  the  information  required  by  the 
system  to  perform  accurate  predictions.  Database  functions  will  be  provided  to  view  parts 
across  technology,  package  style,  supplier,  etc. 

The  advantages  of  the  comprehensive  DMSMS  management  system  we  describe 
are  that  the  automated  prediction  process  results  in  faster  DMSMS  processing  and  allows 
engineers  to  deal  with  the  hard  problems  and  prioritize  their  tasks.  It  is  proactive  so  that 
obsolescence  issues  are  identified  earlier.  It  provides  guidance  through  the  solution 
process  and  coordination  of  solution  efforts.  It  may  be  straightforwardly  expanded  to 
include  other  types  of  parts  (resistors,  capacitors,  mechanical)  and  it  is  owned  and 
controlled  by  the  Navy. 

Our  Phase  II  Design  includes  the  following  major  functionality: 

•  Parts  list  research  functions.  Users  need  the  capability  to  research  the  components 
in  their  parts  lists  to  identity  the  actual  part  numbers  and  alternative  part  numbers. 
Users  will  not  always  start  with  manufacturer  part  numbers.  They  may  have  an 
NSN,  an  SCD  Number,  or  a  MIL-SPEC  number,  and  they  may  not  be  aware 
which  of  these  they  have.  These  functions  will  help  them  identify  which 
representation  they  have.  This  information  would  be  shared  between  Navy 
functions  so  that  the  results  may  be  shared.  For  example,  one  SCD  may  be  used 
on  multiple  systems,  and  once  it  is  researched  for  one  system,  the  results  of  the 
research  are  available  to  all  other  systems. 

•  Weapon  System  to  parts  breakdown.  This  capability  allows  the  users  to  enter  the 
complete  breakdown  of  systems  to  units/assemblies  to  parts.  This  information  is 
required  to  perform  system/unit  assessments  and  to  process  DMSMS  notifications. 

•  Part  DMSMS  predictions.  A  prediction  algorithm  which  automatically  gives  each 
part  a  DMSMS  grade.  This  function  was  the  primary  focus  of  our  Phase  I 
prototyping  efforts. 
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•  Unit/System  DM SMS  assessments.  These  assessments  present  the  DMSMS 
grades  for  the  parts  within  the  unit  or  system.  These  reports  would  be  used  by 
weapon  system  managers  to  proactively  manage  DMSMS  by  prioritizing  redesign 
efforts/budgets.  The  up-to-date  assessments  need  to  be  available  on-line,  and 
managers  of  the  systems  should  be  provided  with  notifications  when  the 
assessment  changes. 

•  DMSMS  notification  processing  against  units/systems.  With  the  weapon  system 
breakdowns  available,  DMSMS  notifications  downloaded  from  GIDEP  can  be 
checked  against  the  breakdowns  so  that  the  affected  systems  can  be  identified  and 
the  appropriate  system  managers  notified.  If  managers  are  proactively  utilizing  the 
unit/system  assessments,  they  should  not  be  surprised  by  these  notifications  if  the 
part  predictions  are  accurate.  Thus,  they  will  be  able  to  more  accurately  respond 
to  requests  from  logistics  personnel  on  LOT  buy  queries. 

•  Coordination  and  tracking  of  solutions.  Because  the  weapon  system  breakdown 
for  all  systems  will  be  available  in  the  system,  multiple  systems  affected  by  the 
same  parts  can  be  identified,  and  their  solutions  shared  if  appropriate  (solutions  for 
one  system  may  not  be  appropriate  for  other  systems).  Additionally,  solutions 
from  other  systems  and  solutions  to  similar  parts  problems  from  the  past  will  be 
available  for  review  (using  case  based  reasoning  techniques)  in  solving  new 
problems.  This  function  will  also  allow  the  tracking  of  past  cases.  Tracking  past 
cases  is  important  where  LOT  buys  were  performed  to  identify  any  future 
inventory  problems. 

•  Analysis  of  data  within  the  system.  With  all  the  Navy  DMSMS  data  in  the  system, 
previously  impossible  studies  can  be  performed  on  the  data  to  identify  trends  or  to 
perform  any  number  of  Navy-wide  analyses. 

•  Solution  identification  tools.  The  system  will  contain  utilities  to  aid  the  DMSMS 
solution  process.  The  availability  of  prior  cases  and  their  solutions  mentioned 
above  is  one  such  tool.  Other  tools  such  as  future  required  inventory  calculations 
based  on  past  use  and  reliability  are  also  needed.  An  on-line  version  of  the  Navy 
DMSMS  Case  Solutions  Guide  would  be  included. 


24 


Preliminary  Architecture  of  Phase  II  DMSMS  Management  System 


25 


7.2  Rationale  for  the  Approach 

During  Phase  I  we  concentrated  on  automating  the  largely  manual  obsolescence 
prediction  currently  performed  by  the  MOM  program.  Our  reasons  for  concentrating  on 
automating  the  MOM  prediction  process  are: 

•  Commercial  prediction  systems  such  as  TACTech  AIM  and  Uwohali's  ECOM  do 
not  cover  all  parts.  If  a  part  is  not  in  the  system,  no  prediction  is  available.  It  is 
important  for  the  prediction  process  to  be  under  the  Navy's  control  so  that  new 
parts  may  be  added  to  the  system  as  needed  by  the  Navy.  Program  managers  want 
to  know  the  status  of  all  the  parts  in  their  systems,  80%  or  90%  of  the  parts  is  not 
enough. 

•  The  life  cycle  code  provided  in  systems  such  as  TACTech  simply  reveals  how  old 
the  technology  is,  not  when  the  part  will  be  obsolete. 

•  The  MOM  program  is  the  only  program  in  the  Navy  which  performs  its  own 
predictions.  Other  organizations  utilize  prediction  results  from  other  prediction 
systems  to  perform  unit  or  system  prediction,  but  they  do  not  perform  the  actual 
prediction  for  parts  themselves. 

•  The  MOM  prediction  process  is  comprehensive  and  does  not  concentrate  solely  on 
the  technology  family  life  cycles  for  the  prediction.  Additionally,  MOM  utilizes  the 
function  and  complexity,  whether  the  part  is  military  qualified,  the  device  package 
style,  the  number  of  sources,  the  reliability,  the  future  market  demand,  emerging 
technologies,  and  preferred  new  products. 

Despite  the  capabilities  offered  by  MOM,  the  process  is  largely  manual,  performed 
by  engineers  with  considerable  experience  in  the  microcircuits  domain.  By  automating  the 
MOM  process,  novice  users  can  perform  at  the  same  level  of  competence  as  senior 
engineers.  In  fact,  a  parts  obsolescence  engineer  may  not  be  required  for  most  of  the 
evaluations.  His  time  is  better  spent  focusing  on  the  more  difficult  problems  requiring 
parts  research.  Automation  of  the  process  permits  recording  of  an  audit  trail  of  the 
evaluation  process  and  produces  more  consistent  evaluations.  Results  of  evaluations  can 
be  automatically  promulgated  to  relevant  users  for  increased  proactivity.  Finally,  if  the 
Navy  hopes  to  address  its  obsolescence  issues  in  a  consolidated  manner,  the  MOM 
program  in  its  current  configuration  would  not  have  the  manpower  to  process  all  the 
evaluation  requests.  Automation  is  clearly  called  for. 

7.3  Innovations  and  Intelligent  Features 

Our  solution  for  obsolescence  prediction  and  DMSMS  management  is  innovative 
and  intelligent.  These  features  are  listed  in  the  following  two  sections. 
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7.3.1  Innovations 


Innovation  #1 :  Applying  CBR  to  the  Domain  of  Obsolescence  Prediction.  CBR 
techniques  have  not  widely  been  applied  explicitly  to  this  domain. 

Innovation  #2:  Capturing  the  Solution  Process.  In  Phase  II  we  will  be  attempting  to 
capture,  for  later  presentation,  the  process  of  developing  a  solution,  as  well  as  the  solution 
itself  We  will  be  generating  information  which  will  be  usellil  in  performing  retrieval  and 
for  providing  explanations  to  users  who  are  trying  to  understand  the  solution. 

Innovation  #3:  Knowledge  Engineering  Tools.  Phase  II  will  develop  procedures  for 
carrying  out  CBR  knowledge  engineering,  along  with  tools  for  supporting  system 
developers  in  the  knowledge-engineering  task.  Knowledge  engineering  required  to 
construct  an  expert  system  entails  considerable  effort.  CBR  is  a  prime  candidate  for 
system-aided  knowledge  elicitation  because  of  the  simple  nature  of  the  development 
process.  We  are  not  trying  to  model  a  world.  We  merely  must  find  out  which  analogue 
cases  are  relevant,  and  why,  and  when  to  consult  them.  By  a  systematic  "unpacking"  of 
the  rationale  behind  problem  solution,  CBR  allows  the  system  developer  to  encode  expert 
knowledge  reliably  and  efficiently.  The  next  step  is  to  provide  the  developer  with 
automated  support.  Because  there  are  very  detailed  records  of  existing  components,  tools 
that  accelerate  the  transfer  of  information  from  files  to  the  case  base  will  be  of  great  use. 

Innovation  #4:  Learning.  By  providing  a  feedback  mechanism,  the  system  will  "learn" 
from  its  mistakes  and  actually  improve  the  accuracy  of  predictive  assessments  over  time. 
This  innovation  ties  CBR  with  the  work  being  done  in  classic  machine  learning. 

Innovation  #5:  Augmented  Retrieval.  CBR  researchers  have  developed  a  number  of 
retrieval  methods,  and  retrieval  is  a  major  issue  in  the  construction  of  a  usable  system.  It 
is  time  to  provide  users  with  support  in  managing  the  retrieval  options,  by  allowing  several 
options  to  be  run  simultaneously  and  by  providing  guidance  about  which  options  to  select, 
as  a  function  of  the  task  parameters  and  the  data  base  characteristics. 

Innovation  #6:  Rapid  Retrieval.  We  have  developed  generic  definitions  of  similarity 
which  allow  very  rapid  retrieval  of  cases  from  very  large  case  bases.  In  Phase  II,  if  these 
definitions  are  not  applicable  to  this  domain,  new,  high  speed  algorithms  and  their 
accompanying  definitions  of  similarity  may  have  to  be  developed. 

We  believe  that  these  innovations  significantly  extend  previous  CBR  work  and 
help  to  ensure  the  useability  of  the  proposed  system. 
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7.3,2  Intelligent  Features  of  the  DMS3  Solution 


Prediction 


•  Automatic  proactive  notification  to  relevant  users 

•  Models  the  human  decision  process 

•  CBR  to  identify  predictive  family 

•  Inherent  use  of  similarity  for  data  field  comparisons 

•  Audit  trail  of  evaluation  process 

•  Ability  to  learn  trends  over  time 

•  Explanation  of  evaluation  code  is  constructed  dynamically  and  shown  to  user 

•  Makes  use  of  trends 

•  System  knows  when  it  does  not  know  information  and  can  tailor  a  request  to  the  user 
to  provide  the  information  (e  g.  size  or  speed  needed  for  family  identification) 

•  Can  find  all  weapon  systems  containing  a  part  from  weapon  system  to  parts 
breakdown 

•  Evaluations  ripple  to  other  affected  systems  (do  not  need  to  receive  DMS 
notices) 

•  Evaluations  can  be  performed  automatically  for  parts  similar  to  obsolete  part 

•  Evaluations  with  dates  can  be  kept  for  future  use  in  tracking  performance  and  using 
CBR 

•  Evaluation  for  one  part  may  be  automatically  applied  to  all  equivalent  parts 

•  Ability  to  evaluate  an  evaluation 

Solutions 


•  Automated  Decision  Process:  Capture  and  automate  the  decision  process  experts  use 
to  identify  the  appropriate  solution  for  an  obsolescence  problem. 

•  Similarity:  Retrieve  and  consider  the  solutions  to  similar  parts. 

Intelligent  Interface 

•  Questions  asked  of  user  only  when  relevant  and  necessary. 

•  Interface  self-customizing  to  user 

•  Interface  accommodates  all  different  kinds  of  part  numbers 

•  Intelligent  navigation  of  large  hierarchies  in  weapon  system  to  parts  breakdown 

7.4  Importance  of  the  Solution 

Because  DMSMS  issues  are  a  significant  problem  throughout  the  DOD  and 
commercial  industry  as  well,  an  intelligent,  automated  approach  to  parts  obsolescence 
prediction  and  management  will  have  broad  applicability  and  offer  tremendous  benefits. 
These  benefits  include  the  ability  for  program  managers  and  their  staff  to  readily  obtain 
reliable  obsolescence  predictions  specific  to  their  systems,  proactive  notification  about 
parts  of  concern  before  they  are  obsolete,  the  communication  of  obsolescence  problems 
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and  solutions  to  all  interested  parties,  consistent  evaluations  and  significant  long-term  cost 
savings. 

The  DMS3  solution  is  not  limited  only  to  Navy  microcircuit  management.  It  can 
be  applied  generally  to  other  types  of  parts,  other  branches  of  the  Armed  Services,  and 
even  to  commercial  sectors.  If  the  Navy  chooses,  it  may  be  able  to  sell  this  DMSMS 
management  service  to  these  organizations. 

7.5  Issues 

There  are  a  number  of  issues  which  deserve  attention  when  considering 
development  of  the  full-scale  Phase  II  system.  The  issues  and  our  suggestions  for 
lessening  the  impact  of  these  problems  are  given  below: 

•  Obtaining  Weapon  Systems  Breakdowns.  The  weapon  system  to  parts  breakdown 
for  many  systems  does  not  exist.  For  example,  many  black  boxes  were  bought 
without  their  parts  list.  Unfortunately,  the  proposed  system  cannot  address  this 
problem. 

Establish  requirements  such  that  any  new  or  redesigned  systems  are  delivered 
with  complete  parts  lists.  Continue  to  research  parts  lists  as  needed  for  current 
systems. 

•  Data  Standardization  and  Incomplete  Data  The  data  and  descriptions  for  parts  are 
not  in  a  standardized  format  which  could  be  easily  processed  by  a  computer.  Also, 
parts  data  records  may  be  missing  fields  of  information  that  would  be  useful  for  the 
DMSMS  management  process. 

Our  Phase  I  effort  has  addressed  this  problem  and  applied  innovative  methods  to 
solve  this  problem.  The  alternative  is  a  large  manual  effort.  Efforts  may  also  be 
made  to  establish  data  definitions  and  standards  so  data  for  new  or  redesigned 
systems  will  be  kept  in  an  appropriate  and  complete  format. 

•  Protocol  for  DMSMS  management.  Navy  sites  currently  maintain  their  own 
databases  and  manage  DMSMS  differently  from  one  another,  primarily  in  a 
reactive  manner. 

Use  of  a  Navy-wide  proactive  DMSK4S  tool  would  require  programmatic 
changes  in  protocol  and  sharing  of  data  and  solutions.  This  does  not 
necessarily  dictate  consolidation  of  databases  and  loss  of  site  control. 


29 


8  0  PROOF  OF  FEASIBILITY/PROTOTYPE  DEVELOPMENT 

8 . 1  Purpose  of  Prototype  Development 

In  the  Phase  I  research  endeavor,  it  was  necessary  to  thoroughly  understand  the 
domain  of  study,  develop  appropriate  solutions,  and  prove  the  feasibility  of  those 
solutions.  One  very  clear  proof  of  feasibility  is  the  successful  development  of  a  working 
prototype. 

The  prototype  developed  as  part  of  our  Phase  I  research  effort  provided  a  concrete 
proof  of  our  design  concepts.  We  were  able  to  prove  the  feasibility  of  our  knowledge 
representations,  prediction  techniques  and  proactive  management  capabilities. 

In  addition,  the  process  of  developing  the  prototype  provided  important 
information  about  the  design  and  use  of  the  complete.  Phase  II  DMSMS  management 
system,  including  refinement  of  the  prediction  algorithms.  Design  of  the  prototype  served 
as  a  first  pass  at  Phase  II  system  design,  including  the  layout  of  the  user  interface, 
organization  and  implementation  of  the  functionality,  and  development  of  the  underlying 
representations.  By  developing  a  working  automated  prediction  and  management  system, 
we  were  able  to  isolate  difficult  aspects  of  the  implementation,  determine  performance 
issues  relating  to  speed,  memory  requirements  and  hardware,  and  identify  strengths  and 
weaknesses  in  our  software  development  tools.  Ail  this  practical  experience  guided  us  in 
the  final  design  of  the  Phase  II  DMS3  and  permitted  improvements  in  the  efficiency  and 
completeness  of  representations,  algorithms,  and  tool  capabilities. 

Another  important  benefit  of  the  prototype  is  that  it  gives  the  Navy  a  very  visual, 
concrete  understanding  of  our  DMSMS  solution.  Many  of  the  ideas  in  our  prediction 
methods  are  highly  technical  AI  concepts.  It  is  much  easier  to  understand  these  concepts 
when  they  are  realized  in  software.  Further,  by  demonstrating  a  working  prototype  of  the 
DMSMS  management  capabilities,  it  is  very  easy  to  appreciate  the  proactive  nature  of  the 
solution  and  the  ease  of  using  the  tool.  Additionally,  the  prototype  development  effort 
allows  us  to  demonstrate  our  capabilities  as  both  AI  researchers  and  as  programmers.  We 
backed  up  our  ideas  with  working  software  and  proved  that  we  can  implement  significant 
functionality  in  a  relatively  short  time  period. 

8.2  Description  of  the  Prototype  Functionality 

The  prototype  prediction  and  management  system  was  developed  in  less  than  six 
weeks  and  encompasses  significantly  more  functionality  than  originally  planned.  It  was 
implemented  using  IntelliCorp's  KAPPA-PC  development  tool  on  a  PC  486  machine  with 
Microsoft  Windows.  APPENDIX  B  contains  the  details  of  the  prototype  implementation 
and  screen  dumps  corresponding  to  a  demonstration  sequence. 
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The  DMS3  prototype  provides  proactive  notification  of  changes  in  part 
evaluations  to  users  whose  weapon  systems  contain  the  parts  in  question.  A  profile  of  the 
user  documents  the  system  or  systems  the  user  is  concerned  with.  The  changes  in  the 
evaluation  are  readily  available  in  the  Important  Notices  window,  present  by  default  in  the 
main  viewing  window  of  the  prototype.  The  user  may  examine  these  notices  in  greater 
detail  through  a  mouse  click  and  see  explanations  for  the  change  in  the  part's  grade.  These 
parts  may  saved  for  later  solution  processing. 

Evaluations  may  be  initiated  by  the  user  or  triggered  automatically  by  the  system  in 
response  to  DMS  notices  or  pre-defined  evaluation  schedules.  Evaluations  are  available  in 
seconds  for  weapon  systems,  units,  and  parts,  complete  with  explanations  of  the 
evaluation  code  calculation. 

Evaluations  may  generate  action  items  for  the  user  to  carry  out  when  fijll 
automation  is  not  possible  The  list  of  action  items  is  prioritized  for  the  user.  Typical 
actions  include  carrying  out  a  check  of  current  suppliers  for  a  particular  part,  verifying  a 
DMS  notice  by  calling  the  supplier,  and  verifying  the  family  classification. 

The  user  may  examine  and  navigate  the  weapon  system  to  parts  breakdown 
graphically.  The  system,  unit  and  part  hierarchy  is  displayed  with  the  evaluation  codes  of 
the  parts  indicated  through  color  highlighting.  Parts,  units  and  systems  may  be  edited 
through  this  graphical  interface.  Other  fimctions  are  available  to  create,  edit,  delete  and 
evaluate  weapon  systems,  units  and  parts  from  top-level  menus. 

The  prototype  demonstrates  proactive  capabilities  by  showing  automatic 
evaluation,  changes  in  the  important  notices  and  changes  in  the  action  items  when  typical 
events  occur  such  as  DMS  notices,  a  supplier  leaving  the  marketplace  and  advancement  of 
the  date  beyond  the  DMS  notice  deadline. 

The  prototype  also  allows  the  user  to  find  equivalent  parts  using  similarity 
methods,  NSN  searches  and  SCD  searches.  Users  can  also  find  alternate  part  names  using 
similarity  in  case  a  part  name  is  unknown  and  is  possibly  a  typographical  error.  The 
prototype  accommodates  all  kinds  of  part  names  invisibly  to  the  user. 

Other  functional  components  of  the  prototype  include  parts  engineering  which 
gives  the  user  access  to  similarity  definitions,  database  utilities,  trends  analysis  and 
database  functions  for  viewing  of  the  data  by  manufacturer,  technology,  etc.  In  the 
solutions  window,  a  user  can  retrieve  similar  parts  and  examine  their  case  history  and 
request  support  for  determining  the  type  of  solution. 

8 . 3  Results  of  Implementation 

The  prototype  used  35  microcircuit  parts  data  selected  by  MOM  engineers  for 
their  representative  character.  It  also  used  relevant  data  from  IHS,  TTF,  MTA  TACTech 
and  FedLog  for  processing  by  prediction  algorithms.  The  following  results  were  obtained 
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for  the  two  critical  aspects  of  evaluation,  first  the  family  identification,  and  second  the 
evaluation: 

Family  Identification 

Of  the  35  parts,  our  family  identification  methods  could  correctly  choose  the  one 
correct  family  for  25  parts  (71%  correct).  In  the  remaining  10  cases  we  were  able  to 
generate  a  list  of  possible  families  for  each  part  which  contained  the  one  correct  family 
every  time.  The  reason  the  one  correct  family  could  not  be  chosen  was  because  critical 
data  was  missing.  In  one  case  no  data  was  available.  In  four  of  the  cases,  the  speed  of  the 
microcircuit  was  not  specified,  in  one  the  size  was  missing;  in  three,  other  data  was 
missing;  in  one,  the  descriptions  from  IHS,  TACTech  and  SMDs  were  conflicting. 

While  these  types  of  problems  defy  automation,  they  can  be  easily  resolved  by 
asking  the  user  very  specific,  very  trivial  questions,  such  as  "What  is  the  size  of  part 
AD664TD-UN1/883B?"  The  user  can  then  select  the  appropriate  family  from  the  small  set 
of  family  choices  provided. 

Evaluation  Process 


Even  with  minimal  knowledge  engineering  efforts,  the  majority  of  our  automated 
evaluations  matched  MOM  evaluations  exactly.  When  matches  were  not  exact,  the 
evaluation  codes  were  only  off  by  one  grade,  which  MOM  engineers  attribute  to  the 
subjective  nature  of  the  evaluations  (two  engineers  may  produce  slightly  different 
evaluations).  Further  knowledge  engineering  efforts  will  clarify  the  details  of  the 
evaluation  process  and  accommodate  any  inconsistencies  in  TTF  or  other  data. 


9  0  FUTURE  RESEARCH  AND  DEVELOPMENT 

Future  research  and  development  will  encompass  the  activities  listed  below. 
Additional  detail  on  a  Phase  11  effort  will  be  provided  in  the  Phase  II  proposal. 

Research 


•  Thoroughly  evaluate  MOM's  evaluation  codes 

•  Study  MOM  process  in  greater  detail  to  capture  heuristic  knowledge  of  experts 

•  Study  overall  DMS  process  in  greater  detail  to  determine  needs  of  users 

•  Study  decision  process  for  solution  development 

•  Study  integration  issues 

-  Identify  systems  and  databases  required  for  integration 

-  Define  system  interface 


32 


Requirements  Definition 


•  Define  user  model.  Identify  potential  users  of  system  and  their  characteristics  and 
needs. 

•  Work  closely  with  users  to  understand  their  needs  for  llmctionality,  user  interface, 
security,  synchronization  of  updates,  remote  access,  etc. 

•  Decide  platform  for  delivery 

•  Decide  development  tools/  interface  tools  to  use  for  the  implementation 
Refinement  of  Software  Design 

Included  in  this  Phase  I  Final  Report  is  a  preliminary  software  design  and 
architecture  for  DMS3.  Because  considerable  additional  research  will  occur  at  the 
beginning  of  Phase  II,  this  design  will  have  to  be  updated  and  potentially  expanded  in  light 
of  new  requirements,  tool  choices  and  platform  choices.  The  software  design  process 
encompasses  both  definition  of  software  modules  and  the  planning  of  development  tasks. 

Implementation:  Phase  II  DMSMS  Management  System  (DMS3) 

The  implementation,  knowledge  engineering  and  software  enhancement  activities 
are  closely  related,  iterative,  and  may  proceed  in  parallel. 

DMS3  will  be  developed  in  phases  to  permit  periodic  incremental  releases  of  the 
software  to  the  Navy.  This  will  give  the  Navy  maximal  control  over  the  development 
effort  and  permit  feedback  from  users  to  improve  the  software.  Incremental  releases 
facilitate  the  knowledge  engineering  activities,  described  in  the  section  below. 

Because  implementation  of  a  comprehensive  DMSMS  management  system  is  a 
large  and  complex  undertaking,  the  system  will  be  divided  into  logical  functional 
components  or  software  modules.  The  primary  functionality  of  these  modules  may,  for 
the  most  part,  be  developed  independently.  This  gives  the  Navy  the  flexibility  to 
coordinate  the  development  schedule  to  meet  its  most  important  needs  first.  DMS3 
modules  include  obsolescence  prediction,  solutions,  database  functions,  and  user  interface. 
Taking  into  consideration  the  Navy's  priorities,  we  will  likely  focus  first  on  implementation 
of  a  full-scale  version  of  the  obsolescence  prediction  techniques  proved  feasible  in  Phase  I. 

Knowledge  Engineering 

Knowledge  engineering  is  the  process  of  capturing  the  domain  knowledge  of  the 
DMSMS  prediction  and  management  experts.  This  involves  working  closely  over  an 
extended  period  of  time  with  each  of  the  experts  to  observe  them  during  their  work  and 
analyze  their  use  of  DMS3.  From  these  interactions,  we  can  refine  our  user  model  and 
prediction  techniques,  identify  other  aspects  of  DMSMS  management  that  can  be 
automated,  and  capture  important  user  expertise. 
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Software  Enhancement 


Based  on  suggestions  from  users  and  our  observations  of  DMSMS  management, 
prediction  and  case  solution,  we  will  improve  the  DMS3  software.  These  improvements 
include  implementation  of  new  features,  along  with  testing  and  debugging.  An  iterative 
approach  to  software  development  results  in  a  better  final  product  because  the  users  of  the 
software  are  allowed  input  and  adjustments  throughout  the  entire  development  period. 

Documentation  Preparation 

DMS3  software  will  be  accompanied  by  user  documentation.  This  includes  a  user 
guide,  a  tutorial,  an  installation  guide  and  an  on-line  help  facility.  However,  because 
DMS3  is  designed  to  be  extremely  user  friendly,  this  documentation  will  be  primarily  for 
reference  and  technology  transfer  to  other  potential  DMS3  users. 

Installation  and  Training 

Because  DMS3  software  will  be  released  incrementally,  installation  of  each  version 
and  training  on  its  new  features  will  take  place  throughout  the  development  process. 


10.0  CONCLUSIONS 

In  Phase  I,  we  applied  our  AJ  expertise  to  the  problem  of  obsolescence  prediction 
and  DMSMS  management.  We  developed  an  innovative  solution  to  obsolescence 
prediction  by  automating  the  MOM  evaluation  process.  Further,  we  designed  a  proactive 
DMSMS  management  system  which  incorporates  the  prediction  techniques  and  gives 
users  capabilities  well  beyond  any  current  expectations.  The  automated  prediction  process 
results  in  faster  DMSMS  processing  and  allows  engineers  to  deal  with  the  hard  problems 
and  prioritize  their  tasks.  It  is  proactive  so  that  obsolescence  issues  are  identified  earlier. 

It  provides  guidance  through  the  solution  process  and  coordination  of  solution  efforts.  It 
may  be  straightforwardly  expanded  to  include  other  types  of  parts,  and  it  is  owned  and 
controlled  by  the  Navy. 

Through  implementation  of  both  of  these  solutions  in  a  prototype,  we  proved  the 
feasibility  of  our  methods  beyond  a  doubt.  This  effort  laid  the  groundwork  for  the 
successful  implementation  of  the  fully  functional  DMSMS  Management  System  in  Phase 
II 
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APPENDIX  A 


INITIAL  KNOWLEDGE  ENGINEERING  QUESTIONS 


Following  is  the  list  of  questions  used  in  early  interviews  with  specialists  in  the 

DMSMS  field.  The  answers  to  these  questions  provided  useful  background  on  the 

problem  and  a  springboard  for  further  knowledge  engineering. 

1 .  What  is  the  function  of  your  site? 

2.  What  area  of  DMSMS  are  you  involved  in?  What  parts  do  you  work  with? 

3.  Is  historical  data  on  obsolete  parts  available?  What  form  is  it  in?  Can  we  use  it  in 

our  prototype? 

4.  What  information  is  kept  for  the  parts? 

5.  What  information  is  kept  for  the  DMS  case? 

6.  How  many  parts/systems  do  you  track  per  month  or  year? 

7.  How  many  DMS  cases  do  you  handle  per  month  or  year? 

8.  What  is  the  process  you  currently  use  to  deal  with  DMSMS? 

9.  Could  you  step  us  through  several  examples? 

10.  What  tools  or  algorithms  do  you  currently  use  for  parts,  DMS,  etc? 

1 1 .  What  are  the  limitations  of  these  tools? 

12.  What  computer  hardware  do  you  use  (PCs,  Macintoshes,  workstations)? 

13.  Do  you  predict  obsolescence  before  it  occurs  (proactive  vs.  reactive)?  If  so,  how 
(tools,  experience,  guidelines,  rules-of-thumb,  etc.)?  How  accurate  is  the 
prediction? 

14.  What  are  the  communication  requirements  among  sites  dealing  with  DMS?  How 
frequent  is  communication  among  sites? 

1 5.  What  are  the  integration  requirements  with  existing  systems  or  among  databases  at 
various  sites? 

16.  What  do  you  need  in  a  DMSMS  system?  What  are  your  requirements  for 
functionality,  accessibility,  and  user  interface? 

17.  Could  you  recommend  anyone  else  we  should  talk  to? 


35 


APPENDIX  B 


DETAILS  OF  THE  PHASE  I  PROTOTYPE 


B.  1  Details  of  the  Prototype  Implementation 
B.  1 . 1  Predictive  Family  Identification 

One  step  which  MOM  engineers  perform  while  evaluating  parts  is  the  generation 
of  a  standardized  description.  This  description  aids  identifying  which  of  the  1000  TTF 
family  classifications  is  appropriate  for  this  part.  The  first  step  in  our  prototype 
development  was  to  evaluate  the  feasibility  of  automatically  performing  this  predictive 
family  identification  from  the  available  parts  data.  The  MOM  engineers  utilize  primarily 
two  databases,  one  from  IHS  and  another  from  TACTech,  to  perform  this  identification. 

Initially,  we  used  the  ESTEEM  Case-based  Reasoning  (CBR)  shell,  a  commercial 
CBR  tool  developed  by  SHAI,  to  test  matching  the  part  descriptions  available  in 
commercial  databases  against  the  1000  TTF  family  descriptions.  The  Partial  Word  Match 
similarity  definition  was  used  to  compare  part  descriptions  from  IHS  to  the  family 
descriptions.  This  similarity  definition  compares  the  words  of  the  two  strings.  The  part 
descriptions  from  TACTech  were  compared  in  a  similar  manner  to  the  family  descriptions. 
The  initial  results  revealed  the  necessity  to  use  a  standardized  vocabulary  in  the 
descriptions.  These  results  also  indicated  that  the  TACTech  descriptions  contained  much 
more  detail  than  the  IHS  descriptions,  and  because  of  this  fact,  the  TACTech  descriptions 
generated  higher  similarity  scores  with  the  appropriate  families. 

In  the  second  trial,  the  descriptions  were  standardized  using  a  list  of  synonyms  and 
abbreviations.  The  vocabulary  used  in  the  part  descriptions  were  analyzed  and  determined 
to  be  small  enough  to  standardize.  The  TTF  family  descriptions,  the  IHS  descriptions,  and 
the  TACTech  descriptions  were  all  standardized  using  a  small  program.  These 
standardized  descriptions  were  input  to  ESTEEM  and  compared  using  the  same  similarity 
definition.  The  results  of  this  second  trial  were  much  improved.  Analysis  of  these  results 
determined  that  specific  words  in  the  descriptions  should  contain  more  weight  in  the 
similarity  score  than  other  words.  These  "keywords"  were  identified  mainly  as  the  nouns 
in  the  description  such  as  RAM,  EEPROM,  MULTIPLEXER,  and  DRIVER. 

Utilizing  these  results  and  the  fact  that  standard  class  descriptions  were  available 
for  SMDs  ,  the  following  two-step  process  was  implemented: 

1)  The  category  of  the  part  was  computed  The  TTF  family  descriptions  are 
divided  into  the  following  six  categories:  Digital,  Linear,  Interface,  Memory, 
Microprocessor,  and  Custom  The  SMD  classes  were  mapped  against  these 
categories.  For  SMD  parts,  the  category  was  immediately  identified  from  the 
SMD  class.  For  non-SMD  parts,  the  keywords  in  the  IHS  and  TACTech 
descriptions  were  compared  against  a  list  of  keywords  for  each  category.  Using 
CBR  and  this  similarity  definition,  the  most  similar  category  was  determined. 
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Determining  the  category  reduced  the  number  of  possible  TTF  family  descriptions 
by  approximately  1/6. 

2)  Next  the  family  within  the  category  was  determined.  The  following  similarity 
definition  was  used  to  identify  the  family; 


Field 

Similarity  Definition 

Technology 

30 

1  if  exact  match 

0.5  if  same  technology  family,  e  g.  TTL  and 
LS-TTL. 

35 

Partial  Word  Match 

Function 

Description 

35 

Number  of  keywords  in  both  descriptions 
divided  by  the  maximum  number  of  keywords 
in  either  description 

Each  of  the  two  Function  Description  scores  is  the  maximum  of  the  following 
comparisons; 

a)  The  TTF  family  function  description  and  the  IHS  description 

b)  The  TTF  family  function  description  and  the  TACTech  description 

c)  The  TTF  family  function  description  and  the  SMD  class  description. 

The  overall  similarity  score  was  a  weighted  sum  of  the  technology  similarity  score 
and  the  two  function  description  similarity  scores. 
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B.  1 .2  Assessment  Algorithm 


The  generation  of  an  Evaluation  Code  depends  on  many  factors.  The  factors  from 
the  TTF  family  are  the  current  life  cycle  code,  whether  the  function  and  technology  are 
acceptable  for  new  designs,  and  whether  the  market  for  this  function  and  technology  is 
increasing  or  decreasing.  The  other  main  factors  in  the  assessment  are  the  number  of 
current  manufacturers,  the  number  of  manufacturers  which  have  left  in  the  past  two  years, 
and  a  projection  of  the  number  of  manufacturers  in  two  years. 

The  following  table  summarizes  the  assessment  algorithm  implemented  in  the 
prototype; 


Eval  Code 

Requirements 

A  (acceptable) 

-  Part  is  acceptable  for  new  designs 

-  Part  has  military  grade  reliability 

-  There  have  been  no  DMS  notices  for  this  type  of  part  for  2  years 

-  There  is  at  least  one  current  supplier  of  the  part 

-  The  life  cycle  code  of  the  part  is  less  than  Mature 

or 

The  life  cycle  code  of  the  part  is  less  than  Saturated  and 
the  market  for  this  part  is  increasing 

S  (suspect) 

-  Part  does  not  meet  acceptable  requirements 

-  Part  is  acceptable  for  new  designs 

-  Part  has  military  grade  reliability 

-  The  two  year  projection  indicates  there  will  still  be  at  least  one 
supplier. 

-  There  is  at  least  one  current  supplier  of  the  part 

or 

-  Part  does  not  meet  acceptable  requirements 

-  The  life  cycle  code  of  the  part  is  less  than  Declining 

-  The  two  year  projection  indicates  there  will  still  be  at  least  one 
supplier. 

-  There  is  at  least  one  current  supplier  of  the  part 

N  (near  obsolete) 

-  Part  does  not  meet  acceptable  or  suspect  requirements 

-  There  is  at  least  one  current  supplier  of  the  part 

0  (obsolete) 

-  There  are  no  known  suppliers  of  the  part. 

U/R  (under  review) 

-The  unit  part  does  not  have  any  vendor  parts  specified  (i.e  the  part 
is  unknown) 

or 

-The  predictive  family  of  the  part  is  unknown. 
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B.  1 .3  Major  Classes  in  the  Prototype 
Systems,  Units,  Unit  Parts,  and  Vendor  Parts 


The  breakdown  of  a  weapon  system  in  the  prototype  was  simplified  to  be  a  three 
level  hierarchy.  The  system  is  the  highest  level.  It  is  composed  of  units  which,  in  turn,  are 
composed  of  unit  parts.  Unit  parts  contain  a  list  of  equivalent  vendor  parts.  For  example, 
the  unit  parts  could  be  named  by  OEM  drawing  numbers  (SCDs),  SMDs,  NSNs,  or 
vendor  part  numbers  themselves.  The  vendor  parts  listed  in  a  unit  part  have  identical 
form,  fit,  and  function.  Vendor  parts  are  simply  the  parts  which  manufacturers  build  and 
sell.  The  vendor  parts  are  named  by  the  part  number  of  their  respective  manufacturers. 

Families 


Families  represent  classifications  of  vendor  parts.  Two  subclasses  for  families  are 
implemented  in  the  prototype:  SMD  classes  and  TTF  Families.  The  SMD  classes  are  the 
functional  groupings  of  SMDs  listed  in  M1L-BUL-103X.  They  contain  functional 
descriptions  of  the  SMD.  The  TTF  families  contain  the  information  from  the  MOM  TTF 
database.  For  each  of  the  1000  families,  the  prototype  contains  the  following  information: 
technology,  function  description,  current  life-cycle  code,  future  life-cycle  code,  preferred 
function  and  technology  combination  for  new  designs,  and  an  indicator  of  whether  the 
market  demand  is  increasing  or  decreasing.  The  information  from  these  two  sets  of 
families  is  used  to  support  the  assessment  calculations. 

Equivalent  Parts 

The  Equivalent  Parts  classes  contain  lists  of  form,  fit,  and  function  replacement 
vendor  parts  or  candidates  to  use  as  replacements.  The  prototype  contains  two  subclasses 
of  Equivalent  Parts  The  SMDs  class  contains  SMD  information  downloaded  from  the 
DESC  bulletin  board  service.  Each  SMD  object  identifies  its  SMD  and  the  vendor  parts 
which  conform  to  the  SMD.  The  SMD  parts  are  considered  extremely  good  candidates 
for  form,  fit,  and  function  replacements.  The  NSNs  class  contains  information  extracted 
from  the  FEDLOG  system.  NSNs  in  FEDLOG  normally  contain  references  to  SMDs, 
SCDs,  and  vendor  part  numbers.  The  information  in  the  prototype  for  NSNs  was  limited 
to  vendor  part  numbers.  Part  numbers  in  an  NSN  are  not  considered  as  good  candidates 
for  replacement  parts  as  SMD  part  number  lists. 

Vendors  /  Manufacturers 

The  Vendor  classes  contain  information  on  manufacturers  including  their  name, 
cage  code,  and  address. 
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Vendor  Parts 


The  vendor  part  objects  include  the  vendor  part  number,  the  manufacturer,  the 
technology,  the  description,  the  IHS  description,  the  IHS  technology,  the  TACTech 
description,  the  TACTech  technology,  the  predictive  category,  the  predictive  family,  notes 
on  parameters,  and  DMS  notice  information. 

User  Profiles 


The  User  Profile  objects  define  the  users  of  the  system.  These  objects  contain  the 
name  of  the  user,  the  systems  of  interest  to  the  user,  the  phone  number  of  the  user,  the 
organization  of  the  user,  and  the  last  time  the  user  logged  in  to  the  system. 

Cases 


Cases  document  the  actions  and  solutions  for  a  DMSMS  problem.  A  case  is 
created  for  a  vendor  part  affecting  a  group  of  very  similar  units.  The  case  contains  the 
vendor,  the  vendor  part  number  and  the  units  and  systems  to  be  handled  together.  A  log 
of  actions  taken,  such  as  important  phone  conversations  and  their  results,  can  be  recorded 
in  the  case  along  with  the  date  of  the  action.  The  case  can  also  record  important 
information  such  as  cost  estimates  and  LOT  buy  calculations. 

Action  Items 


These  objects  contain  the  actions  which  the  user  must  perform  so  that  the 
assessments  may  be  as  accurate  as  possible.  The  prototype  generates  action  items  when  it 
cannot  completely  assess  the  part  itself  Examples  of  action  items  include  identifying  the 
predictive  families  for  parts  for  which  the  system  does  not  have  enough  information  to 
perform  the  identification  itself  When  the  user  selects  an  action  item,  the  system  provides 
the  user  with  all  the  relevant  information  which  it  possesses  so  that  the  user's  job  is  as 
straightforward  and  painless  as  possible.  In  the  above  example,  when  the  user  selects  the 
identify  predictive  family  action  item,  the  prototype  presents  the  user  with  the  most  likely 
predictive  family  from  the  information  available. 

B.2  Prototype  Demonstration  Sequence/Screen  Dumps 

This  section  contains  detailed  views  of  the  functionality  of  the  prototype  through  a 
typical  user  session.  Section  B.2. 1  contains  a  demonstration  sequence  which  highlights 
the  prototype  functionality.  Screen  dumps  corresponding  in  detail  to  this  sequence  follow 
in  Section  B.2. 2. 

B.2  1  Demonstration  Sequence 

1 .  Type  PARTS  from  the  C;\SHAI\PARTS  directory  in  DOS.  One  user's  screen  will 
appear  and  the  second  user's  screen  will  be  iconized. 
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2.  View  the  Important  Notices  screen  of  the  first  user.  Important  notices  currently 
displayed  show  changes  in  Evaluations  since  the  user  was  last  logged  in. 

Double  Click  on  the  important  notices  (26LS32/BEAJC)  to  show  the  explanations 
on  the  Unit  Part  Evaluation  window  -  both  the  evaluation  explanation  and  the 
DMS  notice  for  the  manufacturer  part. 

Close  the  User  Part  Evaluation  Window. 

3  Select  the  User  Profile...  option  on  the  File  Menu  and  view  information  about  the 
user  and  the  weapon  system  he  is  interested  in. 

Click  OK  to  close  the  User  Profile  editor. 

4.  Click  on  the  Weapon  System  Hierarchy  and  select  Systeml.  Colors  indicate  part 
evaluation  codes 

View  the  hiding  and  showing  of  parts  and  units. 

Close  the  hierarchy  window. 

5.  Select  the  Evaluation  icon,  select  Weapon  Systems,  and  select  System  1 . 

View  the  summary  statistics.  *  in  front  of  Unit  B  -  denotes  a  change  since  the  last 
login. 

Double  Click  on  Unit  B  to  bring  up  the  unit  evaluation.  View  the  summary 
statistics  and  the  *'s. 

Double  Click  on  the  part  IDT61 16SA150TDB  to  show  its  evaluation. 

Close  the  Part  Evaluation  Window. 

Double  Click  on  the  part  54F175DMQB  to  show  its  evaluation. 

Close  the  Part  Evaluation  Window. 

Double  Click  on  the  part  AD664TD-UNI/883B  to  show  its  evaluation. 

Close  all  the  evaluation  windows. 

6.  Expand  the  window  of  the  second  user.  Note  that  he  has  no  important  notices. 

View  his  Weapon  System  Hierarchy  (select  System  2)  and  parts  that  overlap  those 
in  the  first  users  system  (mainly  54LS244DMQB).  Most  do  not  overlap. 
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7.  From  the  demo  title  bar  Events  menu,  select  the  DMS  Notice...  option. 

Enter  a  DMS  notice  for 

part  :54LS244DMQB 

manufacturer  :TEXAS  INSTRUMENTS 

dms  date  :1 -MAY- 1995 

Note  that  an  important  notice  appears  in  each  user's  screen  because  they  both  use 
this  part  in  their  systems. 

8.  From  the  top  user's  window,  select  the  Action  Items  icon. 

Double  click  on  the  Verify  DMS  notice  for  part  54LS244DMQB  and  select  DMS 
Notice  verified. 

Double  click  on  the  Check  Suppliers  for  54LS244DMQB  and  select  Still  in 
Production  for  each  vendor  part.  Then  close  the  Check  Suppliers  window. 

Double  click  on  the  Identify  Predictive  Family  for  part  AT28MC010-12MMB, 
select  "CMOS  IM  EEPROM"  as  the  predictive  family  and  select  OK.  The  part 
has  now  been  evaluated. 

Close  the  Action  Item  Window. 

Open  the  Action  Item  Window  for  the  second  user  and  show  that  the  action  item's 
are  gone  for  him  too. 

Close  the  Action  Item  Window. 

9.  From  the  demo  title  bar  Events  menu,  select  the  DMS  Notice...  option. 

Enter  a  DMS  notice  for 

part  :  SNJ54HC00J 

manufacturer  :TEXAS  INSTRUMENTS 
dms  date:  1 -FEB- 1995 

Note  that  an  important  notice  only  appears  in  the  second/bottom  user's  screen 
because  only  his  system  is  affected. 

10.  In  the  important  notices  screen  for  the  bottom  user,  click  once  on  the 
SNJ54HC00J  line  to  highlight  it. 

Select  Save  on  the  Important  Notices  pseudo-menu  bar  and  select  To  Case.  This 
will  cause  a  Case  for  this  problem  to  be  created.  The  Solutions  Window  will  be 
displayed  with  this  new  case  displayed. 
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Select  the  List  Other  Affected  Systems  option  on  the  Case  Menu.  A  list  of  other 
affected  systems  will  be  displayed  in  a  list  box  on  another  window. 


Double  click  on  the  systems  to  show  that  the  manager  with  his  phone  number  is 
displayed.  Close  the  window. 

Select  Find  Similar  Cases  from  the  Case  Menu.  The  Similar  Cases  window  will  be 
displayed  with  3  similar  cases  with  3  different  solutions. 

Close  the  similar  cases  window. 

Select  Edit  from  the  Case  Menu  and  choose  Case! 2.  This  more  fully  filled  out 
case  is  an  actual  case  from  Keyport's  Necad  system. 

Close  the  Solutions  Window. 

1 1 .  From  the  Events  menu,  select  Change  Date. 

Select  the  Enter  new  date  radio  button  and  enter  a  date  of  15-May-1995. 

Close  the  Change  Date  window. 

From  Important  Notices  screen,  note  that  part  IDT61 16SA150TDB  with  one 
supplier  whose  DMS  Date  was  15-May- 1995  have  changed  to  eval  code  O 
(obsolete)  from  N  (near  obsolete). 

Bring  up  Action  Items  screen  from  the  bottom  user,  and  show  that  the  N  part, 
54LS244DMQB,  which  was  evaluated  2  months  before  has  been  re-evaluated  and 
the  suppliers  must  be  checked  again. 

Change  the  prioritize  to  By  #  Systems  Affected. 

Then  Change  back  to  By  Date. 

Close  the  Action  Items  window. 

12.  From  the  Actions  menu.  Select  the  Supplier  Leaves  option  and  enter  the  following 
into  the  form; 

supplier.  MOTOROLA,  INC. 

date:  1  -Jun-95 

type  of  parts:  Military  parts 

Note  the  Important  Notice  for  changed  grades  of  these  parts. 
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Click  on  the  Action  Items  of  the  top  user  and  view  the  "Verify  DMS  notices"  for 
Motorola  parts.  Only  the  parts  whose  evaluations  changed  were  listed  in  the 
Important  Notices. 

Close  the  bottom  user's  screen. 

13.  Select  Edit  from  the  Weapons  System  menu  and  then  select  System  1 . 

Double-click  on  Unit  B  to  edit  it. 

Click  on  the  Edit  Unit  Details  and  explain  the  detailed  unit  information  -  there 
would  be  more  in  a  Phase  II  system. 

Double-click  on  IDT71256S100DB  part. 

Click  on  Edit  Details  to  show  details  of  part  -  again  more  would  be  provided  in  a 
Phase  II  system. 

Click  on  the  Add  Equal  Parts  button,  and  select  each  of  the  CBR,  NSN,  and  Mil 
equivalent  options.  The  CBR  will  retrieve  more  than  any,  the  NSN  will  retrieve 
some,  and  the  Mil  will  retrieve  no  new  equivalents.  For  each  of  these  select  cancel 
when  the  equivalents  list  is  displayed. 

Double  Click  on  the  first  mfr  part  in  the  list  IDT71256S100DB  from  IDT. 

Close  the  part  and  unit  editors. 

Double  click  on  Unit  A  to  edit  it. 

Select  Add  Part  and  enter  7802301  ME,  an  SMD. 

Double  Click  on  the  part  to  edit  the  part.  The  equivalent  parts  listed  in  the  SMD 
have  been  added 

Select  Edit  Details  and  show  that  the  Military  Number  has  been  filled  in. 

Close  the  Details  and  Edit  Parts  windows. 

Select  Add  Part  on  the  Unit  Edit  window  and  enter  01-253-4263,  an  NSN. 

Double  Click  on  the  part  to  edit  the  part.  The  equivalent  parts  listed  in  the  NSN 
have  been  added. 

Select  Edit  Details  and  show  that  the  NSN  has  been  filled  in. 

Select  Add  Equal  Parts  and  select  Mil  equivalents. 

One  additional  part  will  show.  Select  the  Cancel  option. 

Close  the  Edit  Parts  windows. 
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Select  Add  Part  on  the  Unit  Edit  window  and  enter  PLDC20G10-30WMB,  a 
vendor  part  number. 

Double  Click  on  the  part  to  edit  the  part. 

Close  the  Edit  Parts  window. 

Select  Add  Part  on  the  Unit  Edit  window  and  enter  8775501R,  an  invalid  number. 
Double  Click  on  the  part  to  edit  the  part  and  note  that  no  vendor  parts  are  listed. 
Close  the  edit  windows. 

14.  Open  the  Action  Items  window  for  the  top  user,  and  show  the  Identify  Part 
877550 IR  action  item. 

Double  Click  on  the  action  item,  and  the  part  will  be  researched.  This  will  take 
about  1  minute.  In  a  Phase  II  system  this  would  be  much  faster.  The  list  of 
possible  parts  will  be  displayed.  This  should  have  been  875550 IR,  an  SMD. 

Close  the  Part  Research  and  Action  Item  windows. 

15.  Select  the  Parts  Engineering  icon. 

View  the  System  Action  Items  and  menus. 

Select  Research  Part.  This  performs  the  same  function  which  was  just 
demonstrated. 

View  the  Definitions  options: 

B.2.2  Screen  Dumps 

The  following  screen  dumps  correspond  to  the  actions  performed  in  the 
demonstration  sequence.  Two  screens  are  printed  to  each  page. 
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54LS244DI1QB 

26LS32/'BEnjC 


EvalCoile :  N 
EualCoile :  8 


Action  Items 


Evaluations 


Solutions  Weapon  Sys  Hierarchy  Parts  Engineering 


DMSMS  Management  System  (OMS«)  -  User  2 


RIe  WeaponSyotems  Units  Parts 

Help 

User  Name:  Dave  Jones 

lOrganization:  NAVSEA 

Date:  17  Feb-1995 

1  17-Feb-1995  Unlt3 


Important  Notices 


54LS244DMQB 


EualCode :  N 


Action  Items 


Evaluations 


Solutions  Weapon  Sys  Hierarchy  Parts  Engineering 


_ DMS*  Prototype  Demon^trotian 


Events  Reset  Ejsit 


DMBMS  Menagemeot  System  |OMS*|  “  User  t 


File  WeaponSy  stems  Units  Parts  Hefp 


User  Name:  Jeff  Wilson  |Organizalion:  NAVAIR 


IDale:  17  Feb  1995 


RIe  WeaponSy 


Usei  Name: 


1  17-Feb-1995  Unit3 


54LS244DHQB 


EualCode :  N 


Action  Items 


Evaluations 


Solutions 


Weapon  Sys  Hieraichy  Paits  Engineering 


Prototype  Pemoostrotion 


DMSMS  Management  System  PMS*| '  User  1 


RIe  WeaponSystems  Units  Parts  Help 


User  Name:  Jeff  Wilson  |Organization:  NAVAIR 


ID  ate:  17-Feb-1995 


emt  Save  Delete  Pticnilize 


1  17-Feb-1995  UnltC 

2  17-Feb-1995  UnitB 

3  16-Feb-1995  UnitB 


Action  Items  Evaluations  Solutions  Weapon  Sys  Hierarchy  Parts  Engineering 


Evaluations 


Important  Notices 


AT28nC010-12l1t1B 

54LS244Dt1QB 

26LS32/'BEnJC 


Solutions 


EualCode :  S 
EualCode :  N 
EualCode :  S 


OMSMS  Management  System  (DMS*]  -  User  2 


RIe  WeaponSystems  Units  Parts  Help 


User  Name:  Dave  Jones  Organization:  NAVSEA  Date:  17-Feb-1995 


ave 


1  17-Feb-1995  Unit3 

2  17-Feb-1995  Unit3 


Important  Notices 


SNJ54HC00J 

54LS244DHQB 


EualCode :  N 
EualCode :  N 


Action  Items 


Evaluations 


Solutions 
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Weapon  Sys  Hierarchy  Parts  Engineering 


_ _  Pf  otolype  DeinofistmUoii 


Events  Reset  E^jil 


DMSMS  Manayemunt  System  {DMS*l  -  User  1 


File  WeaponSysfems  Units  Parts  Help 


User  Name:  Jeff  Wilson  lOrgamzalion:  NAVAIR 


important  Nonces 


IDale:  17  Feb  1995 


$ave  0^ete 

Pnoitiize 

: 

1 

i7-Feb-1995 

Unite  AT28MG010-12miB 

EualCode : 

s 

2 

17-Feb-1995 

UnitB  54LS244DHQB 

EualCode : 

N 

3 

16-Feb-1995 

Units  26LS32/BEAJC 

EualCode : 

S 

Action  Items 


Evaluations 


Solutions  Weapon  Sys  Hierarchy  Parts  Engineering 


DMSMS  Management  System  JOMS^)  ^  User  2 


File  WeaponSystems  Units  Parts 

Help 

User  Name;  Dave  Jones 

Organization;  NAVSEA 

Date:  17  Feb-1995 

sfsiwS  _ 

1  Bnit3 


KMWKie 


Units 


Important  Notices 
SKJ5««tC08J 


54LS244DnQB 


EwalCode:  H 


EualCode :  N 


Action  Items 


E  valuations 


Solutions 


Weapon  Sys  Hierarchy  Parts  Engineering 


Solutions;  Casel9 


Case  Resolution 


Pa«t  Number; 
SNJ54HC00J 

S^ystews: 

ISysteinZ 


IffEXfiSnnSsTiufiS^ 

:i|Unit3  ^  ^ 


SOLUTIONS: 

€o«t: 


Case  Log: 


17-Feb-1995  CASE  OPENED 
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SpiMttans:  Cas^iq 

C^se 


Resublfdft 


Delete 


Rfid  Similar  Cases 


List  Other  Affected  Systems 


TEXAS  INSTRUnENTS  INC 


Unite; 


Units 


i7-Feb-19?5  CASE  OPENED 


Soietmest  Casel  9 


Case  Resolution 


rart  Number; 
{SNJ54HC00J 


S|i«teB 

fSyste 


System? 


|Systeril2 


'  _  Vaodof; 

“1  :  iTEXAS  INSTRUtlENTS  1 NC 


Affected  Systems 

Field  teleeon  peotat wpe 


X-4  radar 


Cate  Log;  1= 


17-Feb-1995 
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Case  Resolution 


liiiiiiiiiiiiiiiiMi 

|SNJ54HC00J 


Solutions;  Case19 


Veodofc 

ilTEXfiS  INSTRUriiN^^ 


fSysta 


Ted  Gates  is  the  manager  of  system  SystemS. 
The  manager  can  be  reached  at  (483)  213-3800. 


Case  Log:  •= 


17-Feb-1995  CASE  OPENED 
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Solutions,  Case  19 


Cas«  ftesofution 


l*«it  fluHiber. 


SNJ54HC00J 


TEXAS  INSTRUMENTS  INC 


Similar  Ca^es 


Case  135  Manufacturer:  NATIONAL  SEMICONDUCTOR 
Part  Number:  NN54HC00J/883B 


Si/stems:  Radar 


Units:  Unit  345 
Unit  BQ3 


Case  23 


Solution 

Type:  LOT  Buy  Cost:  $  95.00  per  part 


Manufacturer:  TEXAS  INSTRUMENTS 
Part  Number:  SNJ54HC00U 


Systems:  System  54 


Units:  Unit  C5A 


So lut ion 

Type:  Substitution  Cost:  NA 


Case  310 


Manufacturer:  MOTOROLA 
Part  Number:  54HC58/BCAJC 


Systems:  SQQ-89 


Units:  Unit  X34 
Unit  X35A 


Solution 

Type:  Emulation  Cost:  $1100  per  part 


nesQluliort 


Solutions’  rasc1*l 


Rod  Siiniiar  Oaees 
List  Other  Ahetled  Systems 


TEXAS  INSTRUMENTS  INC 


Units; 


Units 


17-Feb-1995  CASE  OPENED 
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Case  Fle®Df«ti0n 


f*«t  Numbci. 

SNJ54HC00J 

|Systen2 


Vendor: 

(TEXftS  INSTRUHeNTS  INC 


Mnfa: 

lUinitS 


Ca««  Log: 


17-Feb-1995 


fc^i2 


Solutions:  Casci? 


Case  Resolution 


rod  Number; 

6134459-1 

fSonar 


Vendor 


Unitll6 

sUnitllS 

Unit31 


tjy«: 

liteciaiipi 


soumoNs^ 

I  SeeCaseLog 


Co«e  Log; 


02/08/93 

Using  configuration  nanuals,  application  of  2833450  was  identified  in 
Unit  31  of  E<U>4,  Unit  116  of  B,C,D,E(U>3,  Unit  118  of  C,D,ECU>3,  and 
Units  016  and  017  of  BQQ-6. 

Support  reguirenents  thru  2005  will  require  75  pcs  of  6134459-1 . 

Plessey  was  contacted  and  verified  this  device  has  been  "archived”.  It  nay 
be  possible  to  have  a  production  run  made  if  requirements  are  sufficient  to 
warrant . 

No  sub/alt  part  or  SOS  can  be  identified. 

03/10/93 

Discussed  requirements  for  the  next  higher  assembly  with  supply  support 
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Events  ^ 
Change  Date... 


DMS  .  pMSMiS  Man&genient  Systcna  “  User  1 

Supplier  Leaves...  |s  Units  Parts  Help 


Oiganization:  NAVAIR 


IDate:  17-Feb-1995 


EctA  Save  Delete  Fnorilize 


1  17-Feb-1995  UnitC 

2  17-Feb-1995  UnitB 

3  16-Feb-1995  UnitB 


Important  Nnhr  es 


flT28HC010-12MMB 

54LS2'14DMQB 

26LS32/'BEBJC 


EualCode :  S 
EealCode :  N 
EualCode :  S 


Action  Items  Evaluations  Solutions  Weapon  Sys  Hierarchv  Parts  Engineering 


Evaluations 


_ ^SMS  Management  Sv^lem  PMS*|  -  User  2 


User  Name:  Dave  Jones  [OrganizaHon:  NAVSEA 


I 


IDate:  17-Feb-1995 


1  i?-Peb-:i99S  Unit  3 


av«  t> 


2  17-Feb-199S  Unit3 


Importr^nt  Motrees 


S4LS244DMQB 


Euaieoael  R 


EualCode :  N 


Action  Items 


Evaluations  Solutions  Weapon  Sys  Hierarchy  Parts  Engineering 


DMSi*  Pretniype  Damnrtstration 


im 


Events  Reset  Ejsit 


Action  Items 


Evaluations  Solutions  Weapon  Sys  Hierarchy  Parts  Engineering 


OMSMS  Management  Syatem  pMS*|  ~  User  1 


RIe  WeapoflSystems  Units  Parte 

liiiliiiiiMMiWiHiiiiiiiii 

User  Name:  Dave  Jones 

Organization:  NAVSEA 

IDate:  17  Feb  1995 

iBSiMiiiiariiaSsSgaagggmgSem^ 


2  17-Feb-199S  Unit3 


tmpoilunt  Noticuh 


i 

— 

SNJS4H.C00d;::H:::::|:v:'.:: 

EualCoi 

N 

54LS244DMQB 


EualCode :  N 


Action  Items 


Evaluations 


Solutions 
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Weapon  Sys  Hierarchy  Parts  Engineering 


Events  Reset  Exit 


pMSMS  Management  System  (DMS^  “  Usej  t 


File  WeayonSystems  Units  Parts  Help 

User  Name:  Jeff  Wilson  jOrganization:  NAVAIR 

Date:  15  May  1995 

Action  Items  bvaluations  Solutions  Weapon  Sys  Hierarchy  Parts  Engineering 


Evaluations 


Solutions 


PMSMS  ManageineQt  System  PMS^  ~  User  2 


Rife  WeapenSystems  Units . Rarts . Hfe^l|pf  .  . . 

User  Name;  Dave  Jones  |Organization;  NAVSEA  |Date;  1544 ay-1 995 


Action  Items 


Evaluations  Solutions  Weapon  Sys  Hierarchy  Parts  Engineering 


UMS*  f^ototype  Demfenstrallan 


Events  Reset  Exit 


Msnesement  System  User  1 


Hew  £<||t  Delete 

Prioritise 

Action  Items 

t  ■  IS-hay  1995  Check  suppliers  foe  part  of  trhi^ 


17“Feb-1995  Check  suppliers  for  part  Sl>lJS4lid00J  of  unit  Unit3. 
17-Feb-1995  Uerify  DMS  notice  for  TEXAS  I  SNJ54HC00J  on  l-Feb-1995. 


Events  Reset"  Ejslt 


Votofype  uemonst 


DMSMS  Managefnpnt  System  03MSH“  User  1 


_ Aetiep  Items 

Prioritize 

i  lS-nag-1995  By  systems  effpctect  tt3 


17-Feb-199B 

lV-Feb-1995 


SnJ54HC0OiJ  oF  uni.^  Uni.1:3. 

TEXAS  I  SNiS-lHCeej  on  l-Feb-1995. 


Action  Items 


Evaluations 


IS  Solutions  Weapon  Sys  Hierarchy  Parts  Engineering 


DMS^  wetetype  Dememstratten 


Events  Reset  Ejsft 


OMSMS  Manesement  System  IOMS*l  *  User  I 


Action  items 


1  3  Uerify  DMS  notice  for  TEXAS  I  SNJ54HC00J  on  l-Feb-1995 

2  1  Check  suppliers  for  part  SNJ54HC00J  of  unit  Unit3. 

3  1  Check  suppliers  for  part  54LS244DI1QB  of  unit  Unit3. 


User  Name;  Dave  Jones 


lOrganization;  NAVSEA 


|Date;  15  May  1995 


Action  Items 


Evaluations 


Solutions 
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Weapon  Sys  Hierarchy  Parts  Engineering 


Events  lieset  E^ft 


uMS*  Prototype  Deioonstratiani 


DMSMS  Maeagefftept  l^steiR  IDMS^  *  User  | 


sew  Edit  Delete 


Action  Ueiits 


PripriUze 


flS  I  SNJ54HC00J  on  l-Feb-1995. 
SNJ54HC00J  of  unit  Unit3. 
54LS244DMQB  of  unit  Unit3. 


Action  Items 


Evaluations 


Solutions 


Weapon  Sys  Hierarchy  Parts  Engineering 


DM^  Rutolype  DemnnstratJoti 


DMt>M$  Hanaqument  S 


Action  items 


Sew  Edit  Delete  Prioritize 


t  1.5-riap-1995  Check  suppliers  for  part  S4bS2440l1QB  of  un  it  Un it 3 . 


lv-Feb-1995  Check  suppliers  for  part  SNJ54HC00J  of  unit  Unit3 
17-Feb-1995  Uerifp  DMS  notice  for  TEXAS  I  SNJ54HC00J  on  l-Feb-1995. 


Action  Items 


Evaluations 


Solutions 


Weapon  Sys  Hierarchy  Parts  Engineering 


Reset  Exit 


PMS^PfStotyee  Pemoestratiee 

Events 

iH 

Supiptier  Leayes. 

important  Notices 


pMSys  Manafleieent  PMS*|  “  liser  1 


3  Units  Parts  HeCp 


Oiganization;  NAVAIR 


ale;  15  May-1995 


Action  items _ hvaiuations _ Solutions  Weapon  Sys  Hieraichy  Parts  B^eiing 

DMShlS  Manaaement  System  IDMSn-  ttaar  ?  T  T!  \^i*> 

Rtej  WeaitaaSysteias  Ualts  Paris  Help  '  '  ^ 


Evaluations 


User  Name;  Dave  Jones  lOrganization;  NAVSEA  lOate;  15-May-1995 


Action  Items  Evaluations  Solutions  _ Weapon  Sys  Hierarchy  Parts  E^ineering 


.......  Bratolv®.e...Dem»Bstra.t«on ....... .  . 


eset  Exit 


DMSM:^  Manenement 


Erfit  Save  Delete  Pnorrlize 


tmpprtont  Notices 


ale;  15-May-1995 


— .tf—  rr  ■*-'P  '  T  TkX  ^  JV  r"  OTP  1VT> 


;  V  T?- .  -  1  O ••  iS  • 


Sifftier:  Imotorolainc 


Action  Items 


Eite  Wm 


User  Name; 


Action  Items 


Evaluations 


Solutions 


Weapon  Sys  Hierarchy  Parts  Engineering 


Events . ftenet  . 


DMS*  Prototype  Demonstfaiion 


OMS^jtS  Management  System  |DMS^  “  Uscf  1 


FUe  WeappnSy  steins  Units  Parts  He{p 


User  Name:  Jeff  Wilson  lOiganization:  NAVAIR 


Date:  l5-Mav-1995 


£4^  $ave  Delete  Pnorifize 


2  15-I1ay-1995  UnitB 


l_15HBay-i995  UnitB  IIi>T?1256gi00W^  EvalCode:  H 


IDT6116SB150TDB 


EualCode :  0 


Action  Items  Evaluations  Solutions  Weapon  Sys  Hierarchy  Parts  Engineering 


Evaluations 


DMSMS  MantagfcBient  System  PMS^  ~  User  2 


Rte  WeapeitSy&tBsms  Units  Pjirts  Help  . 


User  Name:  Dave  Jones  [Organization:  NAVSEA  [Date:  15-May-1995 


Action  Items 


Evaluations 


IS _  Solutions  Weapon  Sys  Hierarchy  Parts  Engineering 


PMSi*  Protnlyp  e  Demnnstratf  on 


DMSMS  Management  System  jfDMS^  ■*  User  1 


New  edit  Delete 


15-May-1995 

15-May-1995 

15-May-1995 

15-May-1995 


Action  Items 


. 


Check  suppliers  for  part  IDT71256S1O0DB  of  unit  UnitB. 

Uerify  DMS  notice  for  MOTOROL  G208C-100/^BXA JC  on  l-Jun-1995. 
Uerify  DMS  notice  for  MOTOROL  26LS32/'BEf)JC  on  l-Jun-1995. 
Check  suppliers  for  part  54LS244DMQB  of  unit  UnitB. 


Events  ftcsel  Ex« 


user  N 


We  a  p  on  Sy  sf  em  s 


DemnnstfaSan 


DMSMS  Manayemenl  System  (OMS*)  “  User  1 


Units  Parts  Help 


Oiganizalion:  NAVAIR 


Edil... 


Prinirtize 


Important  Notices 


IDT71256S100DB 

IDT6lieSfll50TDB 


IDate:  15-Mav-1995 


EualCode :  N 
EualCode :  0 


Action  Items 


Evaluations 


Solutions  Weapon  Sys  Hierarchy  Parts  Engineering 


DMSMS 
Management 
System  (DMS^)  ■ 
User  2 


!*ft  UMS*  F^atotypn  Peroansl^tian  ^  * 

Ivenls  Hcnet  - - - - ^ - - - 


_ _  OMSMS  Mnnagamant  System  IDMB^  “  User  1 


User  Name;  Jeff  Wilson  lOrganization:  NAVAIR  |bate:  15-May-1995 


UniC  UriitB 


Parts 


Prototype  ueirnDnstraiion 


System;  Systeml 


Relay 


ReSatflGi^  Military 


Action 


€dM  Urat  Detad$ 


System:  Systeml 


Ueinonstratian 


Reset  FjsU 


INAVAIR  demonstration  system 


Prt^aiB  Uaitaiier:  jJeff  Wilson 


Military 


Qtjr  Name 

1  Unit A 


De$c<iptioo 
Anplif ier 


Action 


i  Unite 


Receiuei* 


Adrt  Unit 


Parts  Engineering 


System  (DMS^)  - 
User  2 


1 

1 

1 

Z6LS32/'BEAJC 

54F175DI1QB 

AD664TD-UNI/883B 

BUS/LINE  RECEIUER,  01 FF 
D-TVPE  FLIP-FLOP,  QUADRUPL 
D/'A  CONUERTER.  12-BIT.  QUA 

1 

tPt712S6Sia0DB 

8TATIC  RAM 

1 

iDieiiesAiseiDB 

STATIC  RAM 

1 

54LS244DnQB 

BUFFER  &  BUS/LOGIC  DRIUER, 
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Unit;  UfiHB  PartNumben  }0T?1 2SfiS1 0008 


IKTEGRftTEB  DEOI  10X7125681 00BB 


eittOBsiratioQ 


Syatefn:  giystemi 
UnitiUnitB 


Pw’tWwmfcer; 


Action 


IBM  Federal 


£dit  ilMt  0etaa« 


e  OemBnatration 


System:  Systemt 

Unit  UsttS 


Destmi^km:  STATIC  RAM 


Cnuivalent  f  adK 


P«t 


pTSTIN  SEMICOND 
ImOTOROLO  INC 
NATRfl-HARRIS  SE 


riT5C2568CU-100883 

6206C-100/BXflJC 

HI11E-65756NMB 


Action 


AddEi^Patt 


Etfift  Urat  Deta3$ 


Parts  Engineering 


ts  Engineering 


Events  Reset  EhH 


User  Nam 


eii 


Pys^  Pi^al&type  Den]ion»str3ti«n 


PartIDT7l25dS100DJ3 


NSN*  fWP 


Action 


|886(S2GIX 


OWWiegfKftWfcelet  |43816  87 


Teelawla^  jCMOS 
Package;  |nn> 

|  DiialI»Lme  II 
lOOjOOnsDelay  _ 

rsMesi  T5f 


QK  I  CaHreli  liasei 


UMS"  Prototype  Demonskratieo 

'-Reset' Ejjil  \ s.  -  --  ,,  . 


System;  Systcml 


Unit:  Unite 


Unit:  UijHB  PartNuinber;  iDT71  Z56S1 OOOB 


User  Nam 


&«*»ipt>qn:  |STATIC  RAM 
equivalent  Parts; 


Action 


15-Mav-1995 


ts  Engineering 


15  May-1995 


ts  Engineering 


mm 


Events  Reset  EmU  : 


Bystem;  By&temi 


UnltrUsie 


Unit:  UsHB  PartNmutter:  IOT?1 2SfiS1 80BB 


D«»fa»p8sti:  STATIC  RAM 
Enuivaieirt  Part*; 


15-Mav-1995 


Vetidw 

|TNIH6BftTED  DEUI  IDT71256S100nR 

IRUIEIIN  SEMICOND 

mbC2b68CU-100883 

;  MOTOROLA  INC 

6206C-100/BXAJC 

HATRA-HARRIS  SE 

HM1E-6B7B6NMB 

Select  similai  parlir  to  add  to  the  above  fist: 

Part  Nundicr 

ts  Engineering 
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Unit:  Units  PartNinuber:  iOT?1 2SfiS1  BOOB 


tHTEGIMYED  DEO!  I DX7i2S6S  1 001)B 


rNTE QMrE] 


Sfae^uR^jns 


pyti^  i'’g>>tn{ype  Dcjfl c naUMi on 


Evealg  Hesjl-  Esjlt; 


Syatem:  Systemi 
Unit:  Unite 


OotedpCbti:  STATIC  RAM 


Equivafeot  Parts: 
IVondof 


AUSTIN  SEMICOND 
MOTOROLA  INC 
MATRA-HARRIS  SE 


MTSC2568CU-100883 

6206C-100/BXAJC 

HM1E-65756NMB 


Action 


_ Select  tiaaiat  p»ts  to  add  to  ttie  above  fist 

jMiCRON  TECH NOLO 
OMNI-UAUE  SEMIC 
INOUA  MICROELEC 


MT5C2B68C-100 

OW62256CD3-10 

S32K8-100MC 


QMS*  Prototype  Demonstratton 


System:  Systeml _ 

_ Unit:  Unite _ 

Unit:  UriilB  PartNuinber:  iDT?1 258S1 OOOB 


Oe«»ipdo«:  STATIC  HAM 


EfpiivaiefA  Pods: 


Action 


IdElBtOiPad: 


Edit  Unit  Details 


ts  Engineering 


ts  Engineering 


□MS’* 


System:  Systemi 

_ Unit:  Unita 

llnU:  Unite  PartNmnber:  >DT71  gSfiSI  OOnB 


STATIC  RAM 


PwtK 


No  new  equivalents  were  found  among  the  SMDs 


Action 


GetwHic  Part  Nund^ex-i 


CMOS 


|  STATIC  RAM 

.  ;?PS  jcMOS 

thtwifefiw  Cat^aVyj  (memory 


Action 


CMOS  256K  SLOW 


DuallitLine 

lOQjOOnsDeUy 


ts  Engineering 


ts  Engineering 


Totolype  Demons 


System:  Systeml 


Oeyt^idnt  Amplifier 


Ken  Dunn 


Military 


PtncOpiion 

flNftLOG  SUi  tCH/  SPSfr^^W 

ftNflLOG  MULTIPLIER/SQUflKER 
FIELD  PROGRRHIIABLE  GATE  RR; 
EEPROM,  FLfiSH 


Action 


DG202RK/883B 

1595/BCfiJC 

XC2018-33PG84B 

I1D28F020-20/B 


E(M  Umt  Oc»tads 


System:  SyslemT 


1  .  UnltR 


ftnplifloi* 


QMS"  Hototype  Demonstration 


[NAVAIR  demonstration  system 


Prt^ramHairtajaiei:  Jeff  Wilson 


Military 


Percriirtton 


1  llnitB 
1  Unite 


Relay 

Receiver 


Action 


A«W  Unrt 


Parts  Engineering 


System  (DMS^)  ■ 
User  2 


Events  Reset™  Eisjit 


SlBBSi _ 


User  Nam 


0M!>  Hr  nurtype  Dei 


System: 


Unit:  UnitA 


le:  15  May  1995 


DescjdptinR:  Amplifier 

ReliatijUty. 


New  Pail  bi&nttttion: 


Action 


1 

DG202 

1 

1595/ 

1 

XC201 

1 

ND28F 

8PST,  QUAD, 
ER/SQUARER 
RLE  GATE  AR] 


Parts  Engineering 


Evei^s  '  Henet '  fjsft 


)MS*  Prototype  Demonstration 

. . . t.inniii(,^oi.rnini„r . . . . . . 


System:  Syotemi 


Action 


1  OG202AK/883B 

1  1595/BCAJC 
1  XC2018-33PG84B 

1  MD28F020-20/B 


1;  780230iME 


Deeciiptiun 


ANALOG  SUITCH,  SPST,  QUAD, 
ANALOG  nULT I PLI ER/SQUARER 
FIELD  PROGRANMABLE  GATE  ARl 
EEPROM,  FLASH 


Parts  Engineering 
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Events  Reset  EhH 


QMS*  Prototype  Petnonstfaiion 


System:  Systemi 


DMS’  Protntype  Demonstration 


System:  Systemi 


Rte 


User  Nam 


Action 


Amplifier 
Ken  Dunn 
FteKabiN^  (Military 


W««ie 


1  DG202nK/'863B 

1  1595/BCflJC 
1  XC2018-33PG84B 

1  MD28F020-20/B 

1  7802301ME 


1  01-253-4263 


Oeeeiiption 


ANALOG  SWITCH,  SPST,  QUAD, 
ANALOG  tlULTIPLlER/SQUARER 
FIELD  PROGRAI1I1ABLE  GATE  AR 
EEPROn,  FLASH 

LINE  DRIUER/TRANSMITTER,  D 


SWI I GH--MQDE  SUPPLY  Cl  RCU IT 


Parts  Engineering 
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DMS*  Ffotolype  DeniiDnsUiitian 


User  Nam 


Exit 

System:  Systeml 

Unit:  Unit/V 

1 

UtiU:  UnltA  PartNomber;  01-2b3'4263 

15  Mav-1995 


e««aip1«»i:  SWITCH-MODE  SUPPLY  CIRCUIT 
Eqwvalcirt  Parts; 


Action 


Yendw 

SEbGbtE  MICROEL 

IPI52O/88M 

LINEAR  TECHNOLO 

LT1526J 

LINFINITV  MICRO 

SG1526J/'883 

iUNITRODE  INTEGR 

UC1528J/883 

MOTOROLA  INC 

1526/BUAJC 

Is  Engineering 


Erfit  Details 


AddEttoatPigrtt: 


£{|%  iltat 


ArM  Pact 


DMS*  f^Dtotyae 


Fart01-25542tf3 


tbclmalag)!:  |biPOLAR 
Paciu^ei  jDff 


Hie 


Usei  Nam 


Bdtoiype  DenikO»)8lrMtun 


Unit:  UnitA  PattNumber:  01 '253-4263 


15MaH995 


Eveitls  Reset  EjsW 


DMS*  Pfototyae  Uemnnstration 


iiSwm 

Unit  UnitA  PartNombei:  01-263-4263 


Kystem;  Syslemi 


Unit:  Un«A 


15  May-1995 


0e^|ittoi»;  SWITCH  MODE  SUPPLY  CIRCUIT 
Cqutyabet  Pdsts: 


Vemtot 

P«tRwidtet 

SEfliGOtlE  illCROEL 
LINEAR  TECHNOLO 
LINFINITV  MICRO 
UNITRODE  INTEGR 
: MOTOROLA  INC 

lipi526J/883B 

LT1526J 

SG152eJ/883 

UC1526J/883 

1526/BUAJC 

S^ect  tMlai  pait«  to  add  to  die  above  list: 

¥td«lor 

Part  lluiid>f»r 

LINFINITV  MICRO 

SGi52&BJ>883 

Caitcet 
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Events  Read  Exit 


rotolype  ucmottsuationi 


File 


lisei  Nam 


System:  Systeml 


Unit:  UnitA 


|Amplitier 


ReKaiiitay. 


H 

Hi 

i 


Part 


Action 


1 

DG202 

1 

1B9B/ 

1 

HC2&1 

1 

MD28F 

1 

780231 

PLDC20G10  30WM 
Qiaiwi^  n 


1  01-2S3 


Events  Reset  Esjft 


PMS^Rratotype  DemonsU^tion 


System:  Systemi 


Events  Reset  E^it 


py <;toty|)e  Demortsttalion 


System:  Systeml 


Unit:  UnitA 


Usei  Nam 


Unit:  UnitA  PertMumben  PLDC2QS1  a-:30WM8 


jEPLD,  QNE-TiME-PRQGRAMMED 
£({Hiv<ii{ent  Parts; 


15  May  1995 


Action 


Vendor 

CVPRESS  SEMI CON 

PLibC20Gi0-30l)MB 

ts  Engineering 


Edit  Datads 


Add  Equal  Part 


X  rt<wti:i£iM4Xifl“4»vrn«  •  liriiU*  Mncwiniiw«wnwnoi5H:: 


nts  Reset  £3j;lt 


DMS*  Prototype  Demonstration 


S 


U^er  Nam 


1 

DG202A 

1 

1595/1 

1 

HC2016 

1 

nD28FE 

1 

78023C 

1 

01-253 

Parts  Engineering 


1  FL|!l>C2  8vix  j  tiwi  w 


NStlITTER,  D 
PLV  CIRCUIT 


£XXI|/,  vnc- 1 1 1  Ijp-P ROfiRfttH^E®'? 
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He^et  E;slt 


QMS*  Protolype  Dein)»n$tratiQii 


System:  Systemi 


m 


Usei  Nam 


Unl|:  UnM 


Action 


|Ken  Dunn 
QeHistQ^  iMilitary 


1  DG202AK/883B 

1  1595/BCflJC 
1  XC2018-33PG84B 

1  t1D28F020-20/B 

1  7802301ME 

1  01-2B3-4263 

1  PLDC20G10-30UMB 


t  8WSS01R 


ANALOG  SUITCH,  SPST,  QUAD, 
ANALOG  riULTIPLIER/SQUARER 
FIELD  PROGRAMMABLE  GATE  AR] 
EEPROM,  FLASH 

LINE  DRIUER/TRANSMITTER,  D] 
SWITCH-MODE  SUPPLV  CIRCUIT 
EPLD,  ONE-TIME-PROGRAMMED 


Parts  Engineering 


Events  flcset  EisH 


DMS*f¥otolvDe  OemonstrattOB 


Unit:  UnitA  PartNumber:  8775501 R 
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_  DMS* Prototype  Demonstration 


Cidt  ' 


DMSWS  Management  System  PMS^  -  User  1 


iiew  Edit  Delete  PriorHIze 


Action  items 


15  -110  0^1^95  ;  Tile  nt  xf  y  flart  S77S  501 R  of  «h  i  1  Un  it  ft : 


15-Mai;-1995  ChecR  suppliers  for  part  IDT71256S100DS  of  unit  UnitS 
15-May-1995  Uerify  DMS  notice  for  MOTOROL  6206C-100/BXftJC  on  l-Jun-1995. 

15-May-1995  Uerify  DMS  notice  for  MOTOROL  26LS32/BEftJC  on  l-Jun-1995. 

15-May-1995  Check  suppliers  for  part  51LS244DMQB  of  unit  UnitB. 


DMS*  Prototype  Demonstration 


Events  Reset  Ejslt 


DM$MS  Management  System  iOMSH  -  User  1 


Action  Items 


Hew  Idil  ■  Oeiete  Prinritlite'  .  .  . .  . 


15-May-1995  Check  suppliers  for  part  IDT7125GS100DB  of  unit  UnitB. 


15-May-1995 
15-May-1995 
1 5  -Ma  y-tiikiflfia 
15-May-pli 


lOiill 

M 

Sys 

Uerify  DMS  notice  for  MOTOROL  6206C-100/'BXfl JC  on  l-Jun-1995 . 

The  follouing  SMDs  are  sinilar:  ^ 

8775901R 

8755501R 

8775901MR  “1 

7705701R 
8775901S 
87759012 
8755501S 
87555012 
8775901MS 
8775901M2 
85515012 
8551501U 
7705701S 
8759401X 

No  similar  NSNs  uere  found. 

No  similar  SCDs  were  found. 

The  follouing  vendor  part  numbers  are  similar: 

MC1555P1 
SN75114J 


Events  Reset  Ejjit 


OMS^  F/otolype  Denionstfi^rtujfj 


DMSMS  Manaqcment  System  {DMS*1  -  User  1 


ResenrehPnrt  DetinHians  DBUtiimes 

System  Ar44Pti  items 


low  E«t 

F^ioiittze 

;-dui-9s: 

Re^etialuate 

Units  54AG373DI1QB  CEuai;Ci 

ido : A> 

12-Jul-95  Re-eualuate  Unit3  A1020B-PG84B  <Eual  Code  A> 
15-Jul-95  Re-eualuate  UnitB  flD664TD-UNI/'883B  <Eual  Code  fl> 
2-flug-95  Re-eualuate  UnitB  54F175DMQB  <Eual  Code  S> 
2-flug-95  Re-eualuate  UnitB  IDT71256S100DB  <Eual  Code  S> 


DMS*  Prototype  Demonstration 


Events  Reset  E^lt 


DMBMS  Maoaqement  Systern  IDMS^  *  User  1 


File  WeaponSystems  Units  Parts  Help 


12-Jul-95 

15-Jul-95 

2-ftug-95 

2-Aug-95 


Re-eualuate  Unit3  fll020B-PG84B  <Eual  Code  ft) 
Re-eualuate  UnitB  flD664TD-UNI/883B  (Eual  Code  fl> 
Re-eualuate  UnitB  54F175DMQB  <Eual  Code  S> 
Re-eualuate  UnitB  IDT71256S100DB  <Eual  Code  S> 


DMSMS 
Management 
System  (DMS^)  ■ 
User  2 


System  Action  Items 

li2-dui-95  Re  e u a lua t ie  U ri it 3  54AG373 DBQB  <Eual  Code  A  > 
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Parts  Engineering 


Definitions 


/stem  Action  items 


I54Q G373 0lt8B  CEu a  1  Code  ft > 


DMS*PfotPlype  Demonstration 


rveots  nesef  Ei$it 


DMSMS  Manaucmeiit  System  {OMS*]  -  User  1 


Hie  WcaponSystcms  Units  Parts  Help 


Pert  Simltari^ 
Evaluation  Method 
Re-eval  Frequency 


System  Action  Items 


12-JuI-95  Be-  eOalueit 


DMS*  Prutolypc  Dcmonstratioo 


DMSMiS  Management 


Parts  Engineering 


Research  Part  Defioitiono  OB  Udiltieo 


Prioildse 


Code  n> 


DMSMS 
Management 
System  (DMS^)  - 
User  2 


DMSMS 
Management 
System  (DMS=)  - 
User  2 


12-Jul-95 

15-Jul-95 

2-ftug-95 

2-flug-95 


Re-eualuat 

Re-eualuat 

Re-eualuati 

Re-eualuat| 


12-Jul-95 

15-Jul-95 

2-fiug-95 

2-fiug-95 


Re-eualuate  Unit3  ni020B-PG84B  <Eoal  Code  n> 
Re-eualuate  UnitB  nD664TD-UNI/883B  <Eoal  Code  n> 
Re-eoaluate  UnitB  54F175DMQB  <Eual  Code  S> 


Re-eualuate  UnitB  IDT71256S100DB  <Eual  Code  S> 


12 


dul 
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_ DMS*  Demonstratian 


Events  Bcae!  EjsH 


DM^MS  Mananeme^l  $y$tern  -  U^er  1 


File  WeapenSystenis  Unile  Parts  Help 


Definitions 
Part  Slfnilartty 


DB  UtHifies 


Parts  Engine  firing 
Siniii  I  arS  ty  Def initii)  n 


U2-Jta-95 


EvninntEon  MeUiad  ‘  Keywords 
Be-eval  Frequency  Syoonyms/Abbrevlations 


12-Jul-95  Re-eualuate  Unit3  A1020B-PG84B  <Eyal  Code  fl> 
15-Jul-95  Re-eoaluate  UnitB  AD664TD-UNI/'883B  <Eoal  Code  fl> 
2-flug-95  Be-eoaluate  UnitB  54F175DMQB  (Eoal  Code  S> 
2-ftug-95  Be-eualuate  UnitB  IDT71256S100DB  <Eual  Code  S> 


g  J I  1 1  lnn  9  m  tWi  WmI 


Research  Part 


Definitions  MI 


Parts  Engineering 


12-Jul-95 


Re-eval  Frequency 


DMS*  Prototype  Demonstration 


Events  Beset  Ejjjlt  \ 


DMSMS  Management  System  tOMS*1  -  Dserl 


File  WeaponSysferns  Units  Parts  Help 
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DMSMS  ^  U$€r  1 


File  WeaponSystems  Units  Parts  fielp 


Research  Part 


Parts  Engiseering 

Definitions 


m  ^tlii 


12-Jul-95 

15-Jul-95 

2-ftug-95 

2-fiug-95 


Re-eval  Freguepcy  54ftC373DRQB  ft> 


Re-eualuate  Unit3  R1020B-PG84B  <Eual  Code  fi> 
Re-eualuate  UnitB  fiD664TD-UNI/'883B  <Eual  Code  A> 
Re-eualuate  UnitB  54F175Df1QB  <Eual  Code  S> 
Re-eualuate  UnitB  IDT71256S100DB  <Eual  Code  S> 


111  PI  a  1 1 


DWSMS 
Management 
System  (DMS^) 
User  2 


DMS*  Prototype  OeiDiDnstratron 


Events  Resol  Ejslt 


DMSMS  Manaocment  System  (DMS*i  *  User  1 


File  WeaponSystems  Units  Parts  Help 


Parts  Enotneering 


Research  Part  Definitions  DB  Uttlities 


Qi 

t 


1 1 2-d ul -9 5  Re^e  u  a iui 


Re-eViOjiatlaa  Fre^atwnyOn  MuBtkt) 


12-Jul-95 

Re-eualu< 

15-Jul-95 

Re— eualui 

2-flug-95 

Re-eualu< 

2-flug-95 

Re-eualui 

S<Saitj|!ieeO;  16 


> 

de  n> 
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Parts  Engineefisg 


D8  Utilities 


Eual  Code  ft> 


DMU"  P/otutypt;  Ucutonstratian 


Events  Elcset  Eisjit 


Research  Part  Detioitiens 


GIDEP 

{Tpni  fiiz 

Tech.  Trends  Forcast 

ms 

TacTech 

nsnT  ^ 

SMDs 

SCOs 

Maoulactorers 
Data/Trend  Analysis 


Net*  Edit  Prioiiitze 


<Eual  Code  A> 


83B  <£ual  Code  n> 


Re-eualuai 


ual  Code  S> 


>B  <Eoal  Code  S> 


eyaiuati 


12-Jul-95 


15-Jul-95 


2-flug-95 


Be-eualua 


DMSMS 
Management 
System  (DMS^)  - 
Usei  2 
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APPENDIX  C  DATA  REQUIREMENTS  AND  SOURCES 

Phase  I  Prototype  Data  and  Sources 


Data 


Detailed  IHS  parts  data 


TACTcch  parts  descriptions 
SMD  data 


NSN  information 


DMS  Notices 


TTF  database 


Compan>  Information 


Source 


IHS 


TACTech 
DESC  Bboard 


FEDLOG 


MOM  Bboard 


MOM  TTF 


DESC  Bboard 


FEDLOG 


C  ommercial/Governmcnt 


Commercial 


Commercial _ 

Government 


Government 


Government 


Government 


Government 


Govermnent 


Phase  II  Data  Required  and  Possible  Sources 


Parts  data  - 
characteristics  and 
descriptions 


Weapon  S3'stem 
Breakdowns 


(NSN,  etc.) 


DMS  Notices 


TTF  database 


SMD  Information 


SCD  Information 


Solutions/Case  data 


Possible  Sources 

Commerical/ 

Government 

Load  Frequency 

IHS  PartsMaster 

Commercial 

Periodic  updates 

TACTech 

Commercial 

Periodic  updates 

MOM  TAD  database 

Go\einment 

One-time,  initial  source  of  some  parts  data 
from  MTAs  already  performed. 

Weapon  Sj  stems  File, 
ASO  data 

Government 

Initial  load  for  each  sy  stem.  Possible 
periodic  updates. 

MOM  Database 

Government 

Onc-time,  initial  load  for  s}  stems  currenti)' 
in  the  MOM  database 

NECAD 

Government 

One-time,  initial  load  for  systems  currently 
in  NECAD. 

FEDLOG 

Government 

Periodic  updates. 

IHS  Haystack 

Commercial 

Periodic  updates.  Reportedly  better  than 
FEDLOG. 

MOM  obsolescence 
notices 

Government 

One-time,  initial  load  for  existing  notices. 

GIDEP 

Government 

Frequent  (probably  dailj  )  updates  from  fdcs 
downloaded  from  GIDEP. 

MOM  TTF  database 

Government 

Initial  load.  Updated  ever}'  two  years  from 
studies. 

DESC  Bulletin  Board 

Government 

Periodic  updates 

TACTcch 

Commerical 

Periodic  updates 

some  from  Logistics 
Information  -  NSNs 
sometimes  list  SCDs 

sec  Logistics 
Information 

abo\e 

Periodic  updates 

MOM  database 

Government 

One-time,  initial  load 

NECAD 

Government 

One-time,  initial  load. 

other  database  of 
solutions 

Government 

One-time,  initial  load. 

Note:  Periodic  updates  would  probably  occur  monthly. 
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